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SECTION  l  INTRODUCTION 

This  paper  is  an  attempt  to  determine  the  order  of  magnitude  of  the  problem  of  giving  an  axiomatic 
treatment  in  LCF,  of  an  established  programming  language  with  a  sizable  user  community  We 
wanted  to  include  such  features  as  declarations,  I/O,  different  types  of  parameter  bindings  and 
control  structures.  For  this  purpose  we  chose  the  integer  arithmetic  part  of  PASCAL,  which  we  will 
refer  to  as  PASCAL  It  seemed  to  us  a  reasonable  choice  in  that: 

1)  it  satisfies  the  above  criterion,  thus  it  is  not  a  toy  language. 

2)  it  is  powerful  enough  to  compute  any  partial  recursive  function  on  sequences  of  integers. 

3)  the  existence  of  VCGEN  (Igarashi,  London  and  Luckham  1973)  and  FOL.  (Weyhrauch  and 
Thomas  1974)  will  eventually  give  us  th'  ability  to  compare  the  effectiveness  of  Hoare’s 
axiomatic  definition  of  PASCAL,  McCarthy's  style  of  first  order  axiomatization  (McCarthy 
and  Painter  1966)  and  the  Scott  style  of  assigning  extensional  meanings  to  programs. 

One  pleasant  result  of  our  work  was  the  discovery  that  me  task  seems  more  manageable  than  we 
had  originally  thought.  Most  discouraging  was  realizing  exactly  how  inadequate  even  careful 
descriptions  of  programming  languages  actually  are. 

LCF  is  both  a  logical  calculus  and  a  proof-checker  for  a  suspected  proof  in  the  logic  It  could  be 
described  as  an  equation  calculus  based  on  terms  in  the  typed  X-cal.ulus,  whose  most  powerful  rule 
of  inference  is  Kleene’s  first  recursion  theorem  stated  as  a  rule  (see  Kleene  1952).  Using  this 
language  in  the  mathematical  theory  of  computation  was  first  suggested  by  Dana  Scott.  Its  formal 
properties  are  described  in  Milner  1972a,  1972b  Also  see  Milner  and  Weyhrauch  1972,  Weyhrauch 
and  Milner  1972,  Newey  1973,  1974,  Aiello  and  Aiello  1974  for  other  applications.  A  short 
description  of  LCF  syntax  is  given  in  appendix  l 

Initially  cur  intent  was  to  present  a  semantics  for  the  description  of  PASCAL  given  in  Wirth  1971, 
1972  and  Wirth  and  Hoare  1973.  As  a  result  of  our  attempts  to  give  what  me  consider  a  complete 
desci  iption,  we  found  many  ambiguities  and  places  where  the  literal  interpretation  of  Wirth’s 
descriptions  led  to  a  semantics  having  undesirable  properties  (see  3.32.3  for  a  discussion  of  the  for 
statement).  We  have  described  a  language  which  has  a  fairly  smooth  semantics,  and  whose  formal 
propel  ties  are  more  clearly  appaient  All  the  differences  are  documented  in  the  text 

We  think  of  our  axiomatization  as  characterizing  properties  of  the  tuhole  PASCAL  and  not  as  a 
description  of  properties  of  individual  statements.  In  section  4  2,  for  instance,  we  prove  that,  if  two 
programs  P  and  O  don’t  contain  goto  statements,  we  can  represent  the  function  computed  by  the 
progiam  consisting'of  P  appended  to  Q,as  the  composition  of  the  function  computed  by  P  with  that 
computed  by  Q,  This  theorem  and  others  in  section  4  simply  cannot  be  expressed  or  used  in 
foimalisms  like  Floyd's  method  of  attaching  assertions  to  programs  or  in  Hoare’s  axiomatic 
approach  We  consider  this  a  major  difficulty  with  those  techniques  Both  consider  programs 
individually  It  is  our  belief  that  the  feasibility  of  checking  (or  generating)  large  formal  proofs 
depends  on  our  ability  to  prove  general  properties  of  classes  of  piograms.  A  description  of  the 
entire  ,  igrainming  language  is  required  in  order  to  mention  these  classes 

Oharacteriz  ng  an  entire  language  in  this  way  means  that  contlicts  arising  out  of  putting  di  feient 
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programming  features  together  must  be  resolved,  or  at  least  descnbable  in  the  formalism  The 
discussion  of  fund, on  activations  ,n  section  32.1  3  is  a  typical  example  of  the  difficulty  °"' 
encounters  when  trying  to  characterize  the  behavior  of  an  entire  language  Unusual  piogiams 
rannot  be  ignored  or  left  unmentioned.  In  actual  programming  languages  the  ability  to  decide  if  a 
program  is  tell  formed  is  in  general  too  costly  and  many  "ill  formed"  programs  are  usually  accepted 
by  the  parser.  An  example  of  such  a  difficult  case  is  found  in  section  3  3.2.3.  on  the  for  statement. 

In  section  2  we  describe  the  axiomatization  of  the  environment  in  which  PASCAL  programs  are 
execut'd. 

A  special  word  is  needed  here  to  make  clear  an  abuse  of  language  that  appears  throughout  the 
reDort  We  frequently  speak  about  a  combinator  being  executed  and  then  explain  what  it  does. 
Strictly  speaking  this  is  not  correct.  Combinators  don’t  do  anything.  The  functions  we  mention  are 
to  be^ii  terpreted  extensionally.  It  means  that  the  only  properties  of  LCF  functions  that  can  be 
mentioned  are  properties  of  their  graphs  Thus,  when  ‘-oking  at 

F  «  [XN.(isnam«(N)-*(isRichard(N)-*Good,Bad),FF)] 

we  may  say  informally  that  F  is  a  function  which  checks  if  N  is  a  name.  If  it  is  not  then  its  value  is 
FF  otherwise  it  returns  Good  or  B.'d  depending  on  whether  that  name  is  Richard  or  not.  This 
description  is  in  the  style  of  an  interpreter.  More  correctly  we  should  say,  F  is  a  three  valued 
function  whose  value  is  FF  on  arguments  which  are  not  names,  and  otherwise  has  the  value  Good  or 
Bad  depending  or.  whether  that  name  is  Richard.  How  the  function  is  computed  is  tianspaient  to 
LCF  This  point  is  very  important  so  that  there  is  no  confusion  about  the  nature  of  the  semantics 
defined  here  To  each  program  is  assigned  a  function,  not  a  computation  procedure.  LCF  terms 
also  have  interpretations  as  computation  procedures,  but  it  is  not  this  interpretation  that  concerns  us 

here. 

Section  3  describes  all  the  control  structures  and  statements  relevant  to  the  arithmetic  part  of 
PASCAL.  They  include 

1)  type  definitions 

2)  variable  and  array  declarations, 

3)  procedure  declarations  and  procedure  activations, 
i)  function  declarations  and  function  evaluations, 

5)  assignment,  conditional,  while,  repeat,  for-to.for-downto  and  goto  statements, 

6)  input/output  instructions. 

We  do  not  consider  constant  definitions,  label  declarations  (Wirth  1972),  case  or  with  statements,  or 
records  and  files  (except  INP  and  OUT).  These  are  either  easily  addable  or  are  not  relevant  to  tht 

arithmetic  part  of  PASCAL. 

Although  LCF  uses  the  typed  Vcalculus,  a  natural  semantics  may  be  given  to  goto’s  and  to 
procedures  having  themselves  as  actual  parameters  without  introducing  type  conflicts  This  is 

explained  in  section  3  3.1.3. 

Examples  of  general  theorems  about  PASCAL  are  presented  in  section  4  Most  of  the  work  to  date 
on  the  correctness  and  equivalence  of  programs,  has  actually  only  dealt  with  the  extensiona 
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properties  of  algorithms.  Input/output  or  the  effects  of  declarations  cannot  be  ignored  in  any  theory 
of  coircctness  which  hopes  to  be  practical  As  soon  as  we  ask  whether  a  program  will  run  or  not,  or 
whether  it  will  compile  or  not,  then  the  question  "do  we  have  the  correct  algorithm?"  is  a  minimal 
criterion  for  correctness.  In  addition,  the  distribution  and  consumption  of  resources  during  the 
execution  of  a  program,  involves  both  wha'  has  been  declared  and  how  bindings  are  made  to 
parameters.  The  correctness  of  programs  which  input  data  incrementally,  must  know  how  these 
inputs  are  treated. 

We  have  set  out  here  a  description  of  a  large  but  stable  core  for  any  interesting  programming 
language.  We  wanted  to  establish  a  base  from  which  further  work  could  be  done  towards  a  practical 
system  for  proving  properties  of  programs  within  this  core.  Some  example  are  the  theorems  of 
section  4 

Section  5  gives  partial  correctness  proofs  for  some  programs.  The  much  overworked  factorial 
program  is  again  discussed.  We  included  it  to  show  some  of  the  flexibility  in  our  approach  to 
program  correctness  as  well  as  illustrate  points  made  in  other  parts  of  the  report.  A  proof  of  the 
correctness  of  a  progrrm  implementing  the  McCarthy  Airline  reservation  system  is  given  This  is 
new  in  that  it  treats  an  interactive  program  which  has  a  potentiall/  infinite  number  of  inputs  The 
details  are  in  52. 

The  appendices  contain  a  short  description  of  the  LCF  syntax,  the  list  of  all  the  LCF  axioms 
describing  the  syntax  and  semantics  of  PASCAL,  and  the  actual  LCF  printouts  of  the  proofs  of 
theorems  mentioned  in  the  text. 

Some  familiarity  with  the  papers  Wirth  1971,  1972  and  Wirtli  and  Hoare  1973  is  recommended  to 
better  understand  this  memo 
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SECTION  2  THE  SEMANTICS  OF  PASCAL 


Section  2.1  Description  of  the  semantics 

In  this  version  of  PASCAL  we  restrict  our  attention  to  programs  whose  inputs  are  sequences  of 
integers  The  meaning  (or  interpretation)  we  assign  to  a  program  is  thus  a  function  from  sequences 
of  integers  into  sequences  of  integers. 

Programs,  on  the  other  hand,  map  memories  onto  memories  In  order  to  describe  the  effects  of 
procedures  and  function  activations  more  clearly  we  introduce  the  notion  of  a  store  A  store  divides 
the  memory  into /ramrs  or  environments.  Frames  are  specified  by  a  frame  pointer.  Thus  we  think  of 
programs  as  mapping  stores  onto  stores,  and  stores  are  functions  from  framepointers  to  frames. 

store: framepointer  -*  frame 

A  frame  is  a  function  from  locrtions  to  values. 

frame:  location  -»  value 

A  store  describes  abstractly  additional  structure  of  a  memory  without  knowing  how  it  is  realized  in 
any  particular  implementation  The  execution  of  a  program,  p,  starts  with  the  creation  of  the  initial 
store.  This  is  done  by  FRAME0  (see  next  section)  It  contains  the  locations  fileloc  INP  and  fileloc  OUT 
for  the  input  and  output  files  respectively,  and  a  location  textloc  where  the  text  of  the  program  is 
stored.  This  store  has  only  one  frame  called  0. 

Type  definitions  are  then  made  in  this  frame.  Each  frame  represents  an  environment  in  which  the 
current  declarations  and  variable  bindings  are  found 

The  effect  of  declaring  a  variable,  v,  in  a  frame  is  to  create  a  location  typeloc  v,  which  contains  the 
type  of  v.  Thus  we  can  tell  if  a  variable  has  been  declare!  in  a  frame  s(f)  by  checking  if 

s(f,typ«loc  v)«UNDEF. 

The  execution  of  a  procedure  or  a  function  creates  a  new  frame.  It  is  set  up  by  the  combinator 
MAKFRAME  defined  in  appendix  3.9.  The  new  framepointer  is  just  the  successor  of  the  curent  one, 
namely  that  pointing  to  the  frame  where  the  procedure  or  function  has  been  activated.  This 
imposes  a  stack  discipline  on  procedure  and  function  activations.  The  binding  of  free  variables  are 
made  in  the  style  of  ALGOL.  The  petition  of  the  variable  declaration  in  the  program  text 
determines  the  binding  frame.  FETCHV  is  the  function  which  looks  up  the  value  currently  bound  to 
a  variable 

The  combmators  FRAME0  and  MA.TRAME  build  stores  with  the  following  property  If  f  is  a 
framepointer  corresponding  to  a  non  activated  frame,  then  s(f)*UU,  otherwise  for  any  legal  location 
loc,  s(l,loc)  is  either  a  value  or  is  UNDEF.  The  value  of  a  variable  is  stored  in  a  location  which 
depends  on  its  name.  This  is  slightly  complicated  in  PASCAL,  because  both  identifiers  and  array 
element  names  (eg.  A(U)  are  considered  variables  Section  3.2.I.2  describes  the  combinators  which 
allow  us  to  treat  them  uniformly. 
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Both  FRAMES  and  MAKFRAME  store  the  body  of  statements  to  be  evaluated  into  a  location  of  the 
frame  they  are  defining.  The  effect  of  procedure  and  function  declarations  is  to  add  new  locations 
to  the  store 

The  statement  part  of  a  program,  procedure  or  function,  is  interpreted  in  the  store  where  the 
corresponding  declaration  part  has  been  evaluated.  Statements  are  evaluated  in  sequential  order, 
unless  a  goto  statement  is  encountered.  Where  to  go  is  determined  by  the  function  s«gm,  which  takes 
a  text  and  a  label,  and  returns  a  text,  i.e.  it  tel's  you  where  to  jump.  The  new  text  is  evaluated  in 
the  same  frame  as  you  jumped  from.  Thus  you  cannot  jump  out  of  a  procedure  activation.  This 
follows  Wirth  1971  The  effects  of  the  other  statements  are  pretty  much  as  you  might  expect.  They 
are  defined  by  MS  in  section  3.3. 

The  stack  discipline  imposed  on  procedure  and  function  activations  and  the  discipline  imposed  on 
goto’s  are  not  intrinsic  to  this  approach  to  the  description  of  the  semantics  of  programming 
languages.  We  impose  them  because  we  wanted  to  correspond  to  Wirth  1971 

Programs  are  written  in  abstract  syntactic  form  Each  syntactic  construct  is  assembled  by  a 
constitutor  and  its  components  are  selected  by  a  selector.  The  list  of  all  the  axioms  about  the  syntactic 
constructors  and  selectors  are  given  in  appendices  21  and  2.2.  Each  construct  is  identified  by 
associating  a  type  to  it.  A  predicate  is  defined  which  is  satisfied  only  by  objects  of  that  type  (see 
appendix  2.3).  The  equality  of  identifiers  denoting  types  of  syntactic  constructs  and  of  location 
names  is  denoted  by  in  the  formulas  through  the  text  and  is  detected  by  LCF  itself. 


Section  2.2  Top  level  functions 
The  function  FUNCT: 

FUNCT  *  [Xp  o.[Xi.(INPUT®PASCAL(p,o)®OUTPUT)(i)]]  . 

where  ®=[xf  g  x.gU(x))]  is  the  composition  function  and  i,  o  are  sequences  of  integers,  represents  the 
"interface"  between  functions  which  compute  on  integers  and  programs  which  "ompute  on  stores. 

Wirth  1971  describes  a  program  as  a  PASCAL  procedure  which  has  an  input  and  an  output  file  as 
parameters.  The  combinator  PASCAL 

PASCAL  s'  [Xp.[Xo  i.MP(p,0,FRAME0(p,o,i))]3 

when  .applied  to  a  program,  p  is  a  function  which  takes  as  arguments  two  sequences  of  integers  o 
and  i  (representing  the  initialization  of  the  output  and  input  files  respectively)  and  returns  a 
function  from  stores  to  stores.  The  definition  of  PASCAL  imitates  explicitly  the  bindings  which  a 
procedure  would  make  when  executed  as  part  of  a  program.  FRAME0(p)  applied  to  o  and  i  creates  a 
store  containing  a  single  frame,  called  0,  with  these  bindings  and  then  applies  MP  to  the  program  p 
in  frame  0  and  this  store. 

FRAME0  =  [Xp.[Xo  i.[Xf.  (f=0)  -* 

[Xloc  (loc=fileloc  !NP)->  INTERNALREP(i), 

(locMileloc  OUTH  INTERNALREP(o), 

(loc*1extloc)-»  sUtmof(p),UNOEF],UU]]], 
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PASCAL  programs  read  sequences  of  numerals  supplied  by  some  input  device  into  the  buffer  fiUloc 
INP  and  write  outputs  into  the  buffer  filoloc  OUT.  INPUT  is  just  the  identity  function.  The  write 
statement  put'  numerals  in  the  output  buffer,  thus  OUTPUT  maps  sequences  of  numerals,  onto 
sequences  of  integers.  INTERNALREP  is  a  function  which  takes  sequences  of  integers  and  returns 
sequences  of  numerals.  The  definitions  are  found  in  appendix  3.1. 

Programs  in  PASCAL  have  two  parts:  a  declaration  part  and  a  statement  part. 

The  interpretation  of  a  program  in  some  frame  specified  by  the  framepointer  <: 

MP  ■  [Xp  f.MD(d*elof  !,f)«M$(sta»mof  t,f)] 

is  just  the  interpretation  of  definitions  MO  composed  with  that  of  statements  MS.  These  are 
described  in  the  next  section. 
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SECTION  3  DESCRIPTION  OF  THE  LANGUAGE 

This  section  contains  the  lescription  of  all  the  instructions  included  in  our  version  of  PASCAL  and 
the  description  of  their  semantics  in  LCF  Each  text  (it  may  be  a  program,  a  procedure  or  a  function 
text)  consists  of  two  parts:  declaration  part  and  statement  part.  The  semantics  of  a  text  depends  on 
the  frame  in  which  such  text  is  executed,  for  this  reason  a  framepointer  is  specified  as  parameter  in 
every  semantic  function, 


Section  3.1  Declaration  part 

The  declaration  part  includes  type  definitions  and  the  declaration  of  all  the  variables,  functions  and 
procedures  local  to  that  text.  Its  semantics  is  defined  by: 

MD  *  [Xd  f.MDEF(d,f)®MDEC(d,f)], 

MDEF  *  [ecF  [Xd  f. 

isemptyst  d  -*  ID, 

istypedei  d  -»  CREAT(i,namof  d.typof  d), 
iscmpnd  d  -*  F«stoi  d,f)®F(rmdof  d,f),ID]), 

MDEC  *  [«cF.[Xd  f. 

isomptyst  d  -»  ID, 

isvarded  d  -♦  CREAV(f,namol  d.typof  d,f), 
isprocdacl  d  ->>  CREAP(f,namof  d.prspof  d,f), 
isfundecl  d  -»  CREAF(f,namof  d,(nspo<  d.typeof  d,f,<), 
iscmpnd  d  -*  F (fstof  d,f)®F(rmdof  d,f),ID]]. 

MD  is  the  composition  of  MDEF,  which  defines  the  semantics  of  type  definitions  and  MDEC,  which 
defines  the  semantics  of  variable,  procedure  and  function  declarations.  Every  identifier  appearing  in 
a  declaration  statement  is  a  name  so  it  must  satisfy  the  predicate  isname.  Consequently,  whenever 
some  property  of  a  PASCAL  program  is  to  be  proved  in  LCF,  for  each  identifier  appearing  in  that 
program,  axioms  stating  that  it  is  a  name  are  to  be  added.  The  p-edicates  for  the  identification  of 
syntactic  constructs  are  given  in  appendix  2.3. 


3.1.1  Data  Type  Definitions 

Since  we  are  dealing  with  the  integer  arithmetic  part  of  PASCAL  the  scalar  data  types  we  have 
introduced  are  the  integer  type  INT  and  its  subranges.  A  subrange  is  an  interval  of  integers  and  is 
defined  by  specifying  its  lower  and  upper  bounds.  The  structured  data  types  included  in  our 
language  are  the  array  types.  An  array  may  have  3ny  number  of  indices  (each  ranging  in  a  subrange 
type)  and  its  elements  are  all  of  the  same  scalar  type. 

Each  type  may  be  assigned  a  name  in  a  type  defin\ion.  The  semantics  of  a  type  definition  is  CREAT: 
CREAT  «  [Xf  n  ty  s.CREALOC«,s,typidloc,n,ly)]. 

CREALOC  *  [X<  s  loc  n  val.  ISPRESENT(n,s(f)HUU,STORE«,s,loc  n,val)] 
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CREALOC  is  used  by  CREAT.  It  declares  a  name  n  to  be  a  synonym  for  the  rype  ty  in  the  frame  s(»), 
by  storing  ty  in  a  new  location  typidloc  n.  The  result  of  CREALOC  is  undefined  if  n  doesn’t  satisfy  the 
predicate  isname  or  if  it  has  been  already  declared  in  the  current  frame.  This  is  tested  by  ISPRESENT 
Modification  of  the  store  is  done  by  the  combinator  STORE,  Their  definitions  are  in  appendix  3.9. 

In  the  definitions  of  MDEF  and  CREAT  no  assumption  is  made  on  the  order  of  the  type  definitions.  If 
all  the  type  identifiers  satisfy  the  predicale  isnam*  and  are  different  from  each  other,  the  result  of 
MDEF  on  a  frame,  in  which  they  don't  appear,  doesn’t  depend  on  their  order  in  the  text  (see  theorems 
in  4.5' 


3.1.2  Variable  Declarations 

Each  variable  occurring  in  a  text  must  be  assigned  a  type  which  specifies  the  range  of  values  that 
variable  may  assume  during  the  execution  of  the  statement  part  of  the  text.  The  semantics  of  a 
variable  declaration  is  defined  by  CREAV 

CREAV  *  [XI  n  ty  <1  s.CREAlOC(l,s,typ«loe,n,TYPEVAL(»y,fl,s))]. 

CREAV  creates  a  location  in  the  current  frame  s(f),  whose  name  is  typaloc  n,  provided  n  is  a  name  and 
no  other  location  with  the  same  name  already  exists  in  that  frame.  The  content  of  that  location  is 
the  type  associated  with  n  Such  type  is  evaluated  by  TYPEVAL  (see  3.3. 1.3).  Each  type  identifier 
possibly  appearing  in  it  is  removed  and  its  definition  is  substituted  for  it.  The  evaluation  is  made  in 
the  frame  specified  by  the  framepointer  fl.  When  a  variable  is  declared  II  coincides  with  f.  so  at  the 
moment  there  is  no  point  in  introducing  another  parameter  in  CREAV.  We  have  introduced  this 
extra  parameter  since  CREAV  is  also  used  when  binding  value  parameters  in  a  procedure  or  function 
activation.  On  that  occasion  the  two  framepointers  I  and  II  (the  one  in  which  the  new  location  is 
created  and  the  one  in  which  the  type  evaluation  starts)  do  not  coincide. 


3.1.3  Procedure  and  Function  Declarations 

The  semantics  of  a  procedure  declaration  is  defined  by  CREAP: 

CREAP  ■  [XI  n  ps  II  s.$TORE(l,CREALOC(l,s,»cclnk,n,ll),procloc  n,ps)], 

The  result  of  CREAP  is  undefined  if  n  is  not  a  name  or  something  with  the  same  name  has  already 
been  declared  Otherwise  two  locations  are  created.  One  of  them,  whose  name  is  prodoc  n  contains 
the  formal  n^ument  list  and  the  text  associated  to  that  procedure  deda.ation,  the  other  one.  whose 
name  is  acw!  t  n  contains  the  frame  pointer  specifying  the  frame  where  the  procedure  has  been 
declared,  i.e  the  environment  where  its  free  variables  are  bound.  As  for  variable  declarations,  when 
a  procedure  is  declared  the  two  framepointers  I  and  II  are  the  same,  but  the  combinator  CREAP  is 
also  used  when  binding  procedure  parameters  in  a  procedure  or  function  activation,  and  in  that  case 
the  two  framepointers  differ. 

The  semantics  of  a  function  declaration  is  CREAF: 

CREAF  «  [XI  n  Is  ty  It  II  s. 

STORE(l,STORE«,CREALOC«,s,*cclnK,n,ll)ltyp»loc  n,TYPEVAL(ty,lt,s)),«uncloc  n,ls)]. 
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CREAF  is  similar  to  CREAP  The  only  difference  is  that,  in  addition  to  funloc  n  and  acdnk  n,  a  location 
typsloc  n  is  created,  whose  content  is  the  type  of  the  result  of  that  function. 

From  the  definition  of  MDEC  and  the  others  LCF  combinators  describing  the  semantics  of  the 
declarations  it  follows  that  the  order  in  which  declarations  are  made  is  not  relevant.  If  the  identifiers 
being  declared  are  different  and  no  other  locations  have  been  declared  with  these  names  the  same 
store  is  obtained,  independently  of  the  order  (see  theorems  in  4  5).  Tms  is  slightly  more  general  than 
the  definition  of  PASCAL  in  Wirth  1971,  which  requires  that  all  the  variable  declarations  must 
appear  before  the  function  and  procedure  declarations. 


Section  3.2  Expressions 

An  LCF  function  can  either  evaluate  to  an  object  or  to  a  truth  value,  but  not  both  For  this  reason 
we  could  not  introduce  a  unique  evaluation  function  for  arithmetic  and  boolean  expressions.  So  we 
have  divided  expressions  into  arithmetic  and  boolean  (this  distinction  is  absent  in  Wirth  19* I)  and 
introduced  two  evaluation  functions.  Furthermore,  we  have  introduced  a  finer  distinction  between 
the  types  of  operators  in  order  to  avoid  funny  situations  like  the  prefix  adding  operator  "or"  which 
is  allowed  in  the  syntax  given  in  Wirth  1 97 1 ,  1972  but  whose  meaning'  is  not  defined  there. 


3.2.1  Arithmetic  Expressions 

Arithmetic  expressions  are  written  in  abstract  syntactic  form  and  are  evaluated  by  MEXPR: 

MEXPR  *  [ocF.[X«  f  s. 

isconst  «  -*  MCONST  •, 

isoxpr  •  -»isunary(opot  «)  -*  MOPHopof  «,F(arglof  e,f,s)), 

isbinary(opoi  «)-♦  M0P2(opo<  «,F(arglof  •,f,s),F(arg2of  e,f,s)), 
isvariable  •  -a  FETCHV(*,f,s), 

istundss  e  -»  RETURN(suce  l,MF(namof  «,actargof  •,<,s)),UU,UU]]. 

3.2.1. 1  Evaluation  of  Constants  and  Expressions 

The  abstract  syntactic  representation  of  numbers  is  defined  by  the  combinator  mknumconst  If  n  is  a 
number,  mknumconst  n  is  the  corresponding  numeral  and  it  satisfies  the  predicate  isconst  (see 
appendix  2.3).  Numerals  are  evaluated  by  the  stmantic  combinator  MCONST,  which  returns  the 
corresponding  number. 

MCONST  *  [Xx.isconst  x  -*  numof  x,UU]. 

Arithmetic  operator  symbols  appear  explicitly  in  expressions  and  satisfy  the  predicate  isunary  or 
isbinary  according  to  the  number  of  arguments  the  corresponding  operator  expects  (see  definitions  in 
appendix  2l)  When  evaluating  arithmetic  expressions  MEXPR  checks  whether  the  operator  symbol 
is  unary  or  binary,  then  MOPI  or  M0P2  evaluates  them  and  applies  the  corresponding  valui  io  the 
argument(s)  evaluated  recursively 


MOP  1  1  [Xx.x=pplus-*X.x.x,x*pminus-*X.x.{0-x),x*plus  1  -♦succ,x*minusl  -♦pr*d,UU]. 
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M0P2  ■  [\x.x«plus-*l*,x»minus-*!-,x=times-*!*1x*div-»l/,x»rmdr-*mod1UU]. 

M0P1  evaluates  unary  operator  symbols  and  M0P2  evaluates  binary  i  perator  symbols  to  tne 
corresponding  functions.  For  example,  the  meaning  of  the  symbol  plus  if  I  he  LCF  function  ♦  Note 
that,  due  to  the  LCF  syntax,  infix  operators,  when  written  withr.it,  arguments,  are  prefixed  by  ”!” 
An  LCF  axiomatization  of  arithmetic  is  given  in  Newey  1973. 


As  an  example,  if: 

mkexpr2(plus,mk*xprl  (plus I  ,n!  ;,mk*xpr2(fim«s,mknum«onst  2,mk#xprl  (minus  1  ,n2))) 

is  evaluated  in  a  frame  where  '  <e  location  nl  contains  the  value  3  and  the  location  n?  contains  the 
value  7,  its  result  is  16,  i.e.  s*  cc(3)»(2 *pr©d(7 )). 

3.2.1.2  Evaluation  of  Variables 

If  the  expression  to  be  evaluated  is  a  variable,  then  the  corresponding  value  is  fetched  by  the 
FETCHV  combinator. 


FETCHV  *  [ecF  [Xn  <  s. 

ISLOCAL(t\  peloc  NAMOFVAR(n),s(f))-*ISLOCAL(NAMOFVAR(n),s(f)Hs(f,LOCOFVAR(n,f,s)),UU, 

istopf(f)— »UU,F  (VARf3NDT0(n,f,s),NEWFP(n,<,s),s  >]). 

The  fetching  mechanism  is  very  simple  The  variable  to  be  fetched  may  be  an  entire  variable  of  a 
scalar  type  or  an  array  element  In  both  cases  a  test  is  done  (by  ISLOCAL)  to  see  whether  or  not  that 
variable  name  has  been  declared  in  the  current  frame.  If  this  is  the  case,  the  corresponding  value  is 
fetched  in  the  current  frame  (it  will  be  undefined  if  the  variable  has  been  declared,  but  no  value  has 
been  assigned  to  that  location).  If  the  variable  name  has  not  been  declared  in  the  current  frame  and 
the  current  frame  is  not  the  top  one  (i.e.  if  the  fetching  is  done  during  a  procedure  or  function 
activation),  the  binding  list  is  checked  In  fact  the  variable  to  be  fetched  may  be  a  formal  parameter 
passed  by  name  (see  33.1.3  for  details  on  the  binding  mechanism).  In  this  case  FETCHV  applies 
recursively  to  the  corresponding  actual  parameter  in  the  preceding  frame.  If  that  variable  name  is 
not  found  in  the  binding  list,  the  variable  is  free  for  that  procedure  or  function  activation,  hence 
FETCHV  applies  recursively  to  the  same  variable  in  the  frame  specified  by  the  result  oi  NEWFP,  i  e  the 
frame  where  the  procedure  or  function  in  execution  has  been  declared,  hence  where  its  free 
variables  are  bound 

The  definitions  of  the  auxiliary  combinators  used  in  FETCHV  may  be  found  in  appendix  37,-9 
ISLOCAL  performs  a  test  to  ser  whether  a  given  name  has  been  declared  or  not  in  a  frame 
NAMOFVAR  applies  to  a  variable  n,  and  gives  as  result  its  name:  it  coincides  with  n  if  n  is  an  entire 
variable  of  scalar  type,  or  it  is  the  name  part  of  n  if  n  is  an  array  element  Analogously  LOCOFVAR 
returns  the  location  of  n.  As  above,  the  location  of  n  might  be  n  itself,  or  an  array  location  varbndfo 
is  the  function  which  accesses  the  list  of  parameter  bindings  If  the  variable  n  appears  in  it,  then  n 
(or  its  name-part)  is  a  formal  name  parameter  and  the  corresponding  actual  parameter  is  the  result 
of  varbndto  If  n  is  not  a  name  parameter,  then  n  itself  is  the  result  of  varbndto.  In  this  case  n  is  a 
free  variable  for  the  function  or  procedure  in  execution.  NEWFP  evaluates  to  pred  f  or  to  the  content 
of  the  alnk  location  of  the  current  frame,  according  to  whether  n  is  a  formal  parameter  or  a  free 
variable.  The  link  location  is  set  up  when  a  new  frame  is  created  for  a  procedure  (function) 
activation,  it  contains  the  pointer  to  the  frame  where  the  activated  procedure  (function)  has  been 
declared 
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From  the  definition  of  NAMOFVA?  given  in  appendix  3.7  we  see  that  its  result  is  undefined  if  it  is 
applied  to  FUNV  As  explained  in  3.2. 1.3  and  3.3.12  FUNV  is  the  location  where  the  va'uc  of  a 
function  is  stored.  Since  NAMOFVAr.  is  undefined  on  FUNV,  the  result  of  FETCHV  is  undefined  if  it 
applies  to  FUNV.  So  it  is  impossible  to  HreadB  the  value  of  a  function  with  the  usual  fetching 
combinator. 

3. 2.1. 3  Function  Designators 

If  the  expression  to  be  evaluated  is  a  function  designator,  then  a  new  frame  is  set  up.  The  function 
is  evaluated  by  MF  and  its  value  is  retrieved  by  the  RETURN  combinator  in  a  special  location  named 
FUNV 

RETURN  =  [Xf  s.l$LOCAL(FUNV,s(f))-*s(l,FUNV),UU], 

The  semantics  of  a  function  activation  is  very  similar  to  that  of  a  procedure  activation  (see  3.3.1  3) 
Starting  from  a  given  store,  a  new  frame  is  created  by  the  combinator  MFB  and  then  the  semantic 
function  MP  (described  in  section  2.2)  is  applied  to  the  text  of  the  function  The  current  frame  is 
changed  by  incrementing  the  frame  pointer  by  I. 

MF  *  [Xn  a  I.  MFBfFUNCFAUn.O.a.f.nJsMPIFUNCDEFfn.O.succ  I)] 

FUNCFAI.  and  FUNCDEF  are  the  two  functions  which  fetch  from  the  ‘tore  the  formal  argument  list 
and  the  text  of  the  function  being  activated.  Their  definition  is  given  in  appendix  3.8.  They  use  the 
FETCH  combinator  which,  like  FETCHV,  returns  the  content  of  a  location  from  the  frame  where  it  has 
been  created. 

The  activation  of  a  new  frame  and  the  binding  of  parameters  is  done  by  MFB: 

MFB  a  [Xfa  aa  f  n  s.BINDda.aa.succ  l,CREALOC(succ  f.typeloc  FUNVJYPEDEFfn.f.s), 
MAKFRAME(FUNCBOOY(n,f,s),PFLNK(n,f,s),succ  f,s)  ))]. 

It  not  only  binds  the  formal  parameters  to  the  actual  parameters  (the  binding  function  BIND  will  be 
fully  explained  in  3  3.1.3),  but  it  also  creates  a  new  frame  The  frame  in  which  the  function  is 
evaluated  is  set  up  by  MAKFRAME  (see  appendix  3.9).  It  creates  a  location  texiloc  where  the  statement 
part  of  the  text  is  stored,  and  a  location  alnk  whose  content  is  a  pointer  to  the  frame  where  the 
function  has  been  declared.  Moreover,  a  location  lypeloc  FUNV  is  created,  whose  content  is  the  type  of 
the  function  being  evaluated  A  location  named  FUNV  will  eventually  contain  the  value  of  the 
function.  In  fact  Wirth  1971,  1972  says  that  the  function  name  must  appear  at  least  o  e  in  the 
function  text  at  the  left  hand  side  of  an  assignment  statement.  The  value  of  the  function  in 
execution  is  stored  in  the  FUNV  locauon  by  the  combinator  ASSIGN  From  its  definition  in  3.3  I  2  we 
see  that  the  result  of  a  function  can  only  be  assigned  to  FUNV  in  its  function  frame  This  means  that 
if  the  name  of  the  function  in  execution  appears  at  the  left  hand  side  of  an  assignment  statement  in 
the  text  of  a  procedure  where  such  identifier  has  not  b.’en  declared,  it  is  interpreted  as  a  free 
variable,  not  the  nam;  of  the  function  in  execution. 

As  noted  in  3.2.12  the  FETCHV  combinator  returns  an  undefined  value  if  applied  to  FUNV.  This 
implies  that  a  variable  namec  FUNV  cannot  be  declared  even  in  a  frame  different  from  that  set  up 
by  a  function  activation.  We  have  prevented  this  by  considering  FUNV  a  "reserved”  identifier  which 
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doesn’t  satisfy  the  predicate  isnime,  so  it  cannot  be  used  in  declarations  (the  axiom  isname  FUNV^FF  is 
included  in  appendix  2  4). 

We  assume  that  the  translator  from  concrete  to  abstract  syntax  nas  substituted  FUNV  for  all  the 
occurrences  of  the  function  name  on  the  left  hand  side  of  assignment  statements  within  the  function 
text.  If  there  are  no  such  occurrences,  the  function  activation  returns  an  undefined  result  If  there 
are  several,  the  last  executed  determines  the  value  of  the  function.  If  a  variable  identifier  equal  to 
the  name  of  the  function  in  execution  occurs  on  the  rigth  hand  side  of  an  assignment  statement, 
then  either  that  v.umble  has  been  declared  within  the  function  execution  or  it  is  considered  a  free 
variable  of  that  function.  When  a  variable  has  been  declared  with  the  same  name  as  tne  function  in 
execution,  its  value  is  undefined  during  the  function  exe^.  ion  In  fact,  it  cannot  be  assigned  a  value 
since  FUNV  has  replaced  it  on  the  left  hand  side  of  any  assignment  statement.  It  cannot  be  mputed 
since  the  read  statement  cannot  be  executed  within  a  function  activation  (see  the  following 
paragraphs  for  a  discussion  on  side  effects). 

The  declaration  of  a  variable  with  the  same  name  as  the  function  in  execution  is  not  forbidden  by 
Wi-th  1971,  1972,  but  we  do  not  see  any  reasonable  semantics  for  it.  In  addition  Wirth  1971,  1972 
says  thak: 


"Occurrence  of  the  Junction  identifier  in  a  function  designator  within  its  declaration 
implies  recursive  execution  of  the  function". 

This  sentence  doesn’t  specify  what  happens  if  within  a  function  another  function  is  declared  with 
the  same  name  Our  semantics  allows  such  declarations  -  why  not’  In  such  case  the  "outermosi" 
function  cannot  be  executed  recursively  This  is  also  the  case  if  a  function  has  a  formal  parameter 
with  the  same  name  (this  is  not  forbidden  in  Wirth  1971,  1972).  In  this  case  the  corresponding 
actual  parameter  is  executed. 

PASCAL  allows  functions  to  have  themselves  as  actual  parameters  Even  though  LCF  is  a  typed 
logic,  the  semantic  combinators  we  have  defined  avoid  type  conflicts  by  passing  the  text  of  the 
function  and  not  the  function  itself  as  a  parameter.  This  is  also  true  for  procedures  having 
themselves  as  parameters. 

Haberman  1973  is  very  critical  of  the  PASCAL’S  notion  of  function  He  says  that,  while  the  aim  of  a 
PASCAL  function  is  that  of  not  having  side  effects,  this  is  not  true  since  a  function  may  call  a 
procedure  which  may  have  side  effects.  Our  semantics  deals  with  this  situation  in  a  different  way. 
Statements  which  change  the  content  of  a  location  and  hence  cause  side  effects  are  o>  ly  the 
assignment,  .ead,  write  and  for  statements. 

The  read  and  write  statements  modify  the  content  of  the  input  and  output  buffers  so  they  cannot  be 
executed  during  a  function  activation  V\e  forbid  this  by  the  test  ISFUNFP  which  is  performed 
whenever  a  read/write  statement  is  executed.  It  checks  if  any  frame  between  the  current  one  and  the 
top  one  has  been  set  up  by  a  function  activation  (see  3.3. 1  4,-5).  The  trst  on  whether  a  frame  has 
been  created  for  a  function  activation  or  for  a  procedure  activation  is  done  by  checking  in  the  frame 
whether  typaloc  FUNV  is  defined  or  not. 

An  assignment  statement  may  cause  side  effects  by  as>ignmg  a  value  to  a  free  variable.  Whenever 
the  variable  to  be  assigned  is  a  fue  variable  for  tne  current  fnme,  the  ASSIGN  comb  in  a  tor  (see 
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3  3  12),  checks  whether  between  the  current  frame  and  that  where  the  variable  is  bound  (hence 
where  the  modification  of  the  store  actually  takes  place)  a  function  has  been  activated 

The  for  statement  may  cause  a  side  effect  if  its  control  variable  is  free  in  a  function  activation. 
Wirth  1971,  1972  doesn’t  say  that  the  control  variable  must  be  local  to  the  frame  where  the  for 
statement  is  executed.  In  our  semantic  definition  of  PASCAL,  the  for  statement  cannot  cause  side 
effects  in  a  function  activation  since  its  definition  relies  on  the  combinator  ASSIGN  for  updating  the 
control  variable  (see  3.3.2  3). 

We  included  the  above  checks  in  our  semantics  so  that  ill-formed  programs  return  an  undefined 
stoie  It  turns  out,  however,  that  in  our  formalism  no  function  can  cause  side  effects.  This  is  because 
MEXFk  simply  returns  a  value  from  a  function  activation  The  checks  done  in  our  semantic 
combinators  amount  to  checking  for  side  effects  "at  run  time"  Thus  some  programs  which  would  be 
rejected  by  a  PASCAL  compiler  will  still  have  well  defined  meaning  for  us  if  the  statements 
producing  side  effects  are  never  executed 

Finally,  we  want  to  point  out  that  our  semantics  allows  parameters  of  a  function  to  be  passed  by 
name,  but  guarantees  that  those  parameters  can  only  be  "read"  during  the  function  execution  This 
contrasts  with  Hoare’s  opinion  (private  communication)  that  PASCAL  functions  must  not  have 
parameters  passed  by  name  Wirth  1971,  1972  says  nothing  about  it  In  Wirth  1971  the  assignment 
to  nonlocal  variables  is  explicitly  forbidden.  Nothing  is  said  about  this  in  Wirth  1972. 


3.2.2  Boolean  Expressions 

The  evaluation  of  boolean  expressions  is  very  similar  to  that  of  arithmetic  expressions  (see  3.2.1  and 
subsections).  It  is  performed  by  M3EXPR: 

MBEXPR  *  [ceF.[X«  f  s. 

(•*tru«)-»TT, 

(•«f3ls«)-*FF, 

isbexpr  e  -*isbunary(bopof  o)  -*  MGOPKbopof  e,F(barglof  e,f,s)), 

isbbmary(bopof  e)-*  MB0P2(bopof  e,F(barglof  e,f,s),F(barg2ol  e,f,s)), 
isreloptbopof  e)  -*  RELOP(bopof  o,MEXPR(arglof  e,f,s),MEXPR(arg2of  e,f,s)),UU,UUl] 

true  and  false  are  the  abstract  syntactic  representations  of  the  boolean  constants  true  and  false  If  the 
expiession  to  be  evaluated  is  the  constant  true,  then  it  evaluates  to  TT,  if  it  is  the  constant  false,  it 
evaluates  to  FF  Boolean  expressions  containing  unary  and  binary  uperator  symbols  are  evaluated 
like  arithmetic  ones  Relation  operators  take  integers  as  arguments,  so  the  meaning  of  a  relation 
symbol  is  applied  to  its  arguments  evaluated  by  MEXPR.  The  meaning  of  unary  and  binary  boolean 
operators  and  that  of  relation  operators  is  defined  by  MB0P1,  WB0P2  and  RELOP 

MBOPI  s  [Xx.x=no1-»-,UU]p 
MB0P2  *  [Xx.x*and-*,A,xsor-*!v,UU], 

RELOP  s  [Xx.x*lseq-+!<,x*greq-+!>,x=lf-*!<px-gH!>,xseq-*!s,x=neq-*/,UU). 

For  example  in  the  frame  specified  by  the  frame  pointer  f  and  in  the  store  s 
mkbcxprl  (not,mkb«xpr2(or,mkr«l,lt,«,mknuiT\const  0),mkr»l(gt,i,mknumcons»  I))) 
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evaluates  to  i 

\ 

•<((MEXPR(i,f,s)<0)v(MEXPRU,f,s)>  1 )). 

An  LCF  axiomatization  for  the  boDlean  operators  is  given  in  Newey  1973. 


Section  3.3  Statement  Part 

The  semantics  of  the  statement  part  of  the  program  is  defined  by  MS. 

MS=[«;F.[Xst  f 

isompfyst  st  -*  ID, 
iscmpnd  sf  -* 
isemptyst(fstof  st)-+  F(rmdof  st,f), 

islabstaf (fsfof  st)->  F(mkcmpnd(sfatmof(fsfof  sf),rmdof  sf ),l), 
isgoto(fstof  sf)  -*  GOTO(F,labelof(fsfof  st),f), 

isass  (fstof  st)  -*  ASSIGN(lhsof«sto<  st),MEXPR(rhsof (fstof  sf ),f ),f )©F (rmdof  st,f), 
isprocealltfstof  st)-»[\s.MPB(PROCFAL(namof(fsfof  st),f,s),actargof(fslo<  sf),f,s,namof(fsfof  st))]® 

[\s  MD(PROCOECL(namof(fstof  sf),f,s),succ  f,s)]® 

[Xs.F(PROCBODY(namof(fstof  st),f,s),suce  f,s)]»CLEAR(succ  t)®F(rmdof  st,f), 
isread(fstof  st)  -*  READ{namof(fstof  sf ),f )®F(rmdof  st,f), 
iswrita(fstof  st)  -*  WRITE(namof(lstof  st),f)«F(rmdof  st,f), 
iscondtfstof  st)  -»  CONDfMB EXPR(tostof (fsWf  st),f), 

F(append(thenof(fsfof  sf),rmdof  sf ),f ),F (append(elseof (fstof  st),rmdof  st),f)), 
iswhilatfstof  st)  -♦  COND<MBEXPR(tcsfof (fstof  st),f), 

F(append(bodyof(fstof  st),st),f ),F(rmdof  st,f)), 
isr«p«at(fstof  st)  -*  F{append(bodyof(fstof  sl),mkempnd(mkcond(mkb«xprl  (not, 
fesfof (fstof  sf )),fstof  st,ES),rmdof  sf)),f), 
isf orf offsfof  sf)  -♦  COND(MBEXPR(fortesf(fsfof  sf),f), 

ASSIGN(indexof (fstof  sf ),MEXPR(lbof (fsfof  st),f),f)® 

F(append(bodyof(fsfof  sf),forfoup  sf),f),F(rindof  st,f)), 
isfordn(fsfo<  sf)  -*  COND(MBEXPR«orfes<(fsfof  sf),f), 

ASSIGN(mdoxof(fstof  sf),MEXPR(ubof (fstof  sf),f),f)0 
F(append(bodyof (fstof  sf),fO'dnup  sf ),f ),F(r mdof  sf,f)),UU,UU]]. 

The  definition  of  MS  has  the  form  of  a  nested  conditional,  each  branch  corresponds  to  one 
instruction  of  the  language.  Note  that  MS  is  defined  only  on  the  empty  statement  ES,  whose  semantics 
is  the  identity  ID=[Xx x],  and  on  compound  statements  In  fact,  the  abstract  syntactic  form  of  a 
program  is  a  list  of  instructions  assembled  by  the  constructor  mkcmpnd  and  ending  with  the  empty 
statement  E5  When  the  first  argument  of  MS  is  a  compound  statement  a  test  is  done  on  its  first 
element  Except  for  the  labeled  statements,  whose  semantics  is  simply  that  the  corresponding 
unlabeled  statement,  the  detailed  description  of  the  semantic  functions  defining  the  meaning  of  each 
instruction  will  be  given  in  the  following  sections 


3.3.1  Simple  Statements 

We  have  defined  the  semantics  of  all  the  simple  statements  of  PASCAL,  re.  goto  statement, 
assignment  statement,  and  procedure  statement.  Furthermore,  we  have  defined  the  semantics  of  an 
instruction  for  reading  input  data  from  the  input  buffer  INP  and  of  an  instruction  which  writes 
output  data  into  the  output  buffer  OUT 
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3.3.1. 1  Goto  Statement 

The  semantics  of  the  goto  statement  is  defined  by  the  GOTO  combinator. 

GOTO  *  [XF.[Xn  f  F (s«6m(n,TEXT(f )),<)]], 

It  applies  the  semantic  function  MS  recursively  to  the  text  returned  by  the  segm  combinator: 

segn  *  [ocF.[Xn  si. 

isemplysl  st  -*  UU, 
iscmpnd  st-* 

isomptyst(fslol  st)  -*F(n,rmdof  st), 

islabsta*(fstof  st)-*(n=labelof  st)-  st,F(n,mkcmpnd(statmof{fstof  s»),rmdof  st)), 
issingle(fstof  st)  -*F(n,rrrdo<  st), 

isconddsto?  st)  — »occur3(n,thonof (fstof  st))-»appond(F(n,thonof(fstof  s»)),rmdot  st), 
occur${n,elseof (tstof  st))-*Jppend(F(n,elsoof(fi»tof  st)),rmdof  st), 

F(n,rmdof  st), 

isrepwh(fstof  st)  -*occurs(n,bodyof(fstof  st))-*append(F(n,bodyof (fstof  st)),st), 

F(n,rmdof  st), 

istortodstof  st)  -*Oecurs{n,bodyof {fstof  st))— » 

append{F(n,bodyof (fstof  st)),fortoup(st)),F(n,rmdof  st), 
isfordnffstof  st)  -*occurs(n,bodyof{fstof  st))-* 

app«rd{F{n,bodyof {fstof  st)),fordnup(st)),F(n,rmdof  st),UU,UU]]. 

segm  applies  to  a  label,  and  the  text  st  which  is  retrieved  from  the  store  by  the  TEXT  combinator, 
and  returns  the  piece  of  text  starting  from  the  first  occurre  .ce  of  the  label  If  the  label  is  not  found 
in  the  text  the  result  of  segm  is  undefined.  The  behaviour  of  PASCAL  programs  when  seveial 
identical  labels  appear  in  it  is  another  example  of  ambiguity  in  Wirth  1971,  1972.  An  accurate 
description  of  a  language  must  say  if  this  is  a  well-formed  program  or  not. 

In  our  semantics,  no  restriction  is  imposed  on  where  the  label  may  appear  in  the  text.  This  means 
that  jumps  into  (or  out  from)  the  body  of  a  repetitive  statement  are  allowed.  The  behavior  of  segm 
in  such  case  will  be  described  in  their  respective  sections. 

According  to  Wirth  1971  we  do  not  allow  jumps  into  a  procedure  body,  but,  contrary  to  Wirth  1972 
we  do  not  allow  jumps  out  of  a  procedure  activation,  re.  jumps  cannot  cause  the  change  of  the 
current  frame.  For  this  reason  we  have  not  introduced  the  label  declaration  statement  of  Wirth  1972 
since  the  notion  of  scope  for  a  label  is  meaningless  to  our  semantics. 

Lockhood  Morris  and  others  have  suggested  the  notion  of  continuation  as  a  possible  way  of  defining 
the  semantics  of  programming  languages  wiih  the  goto  instruction.  It  cannot  be  used  in  L  3F  in  a 
straightforward  way  since  a  type  conflict  arises.  On  the  contrary  in  our  semantics  no  type  conflict  is 
introduced  by  the  goto,  in  fact  its  semantics  simply  reduces  to  changing  the  first  argument  of  MS. 
The  text  to  De  executed  next  is  replaced  by  the  text  evaluated  by  the  segm  function 

3.3.I.2  Assignment  Statement 

The  semantics  of  the  assignment  statement  is  defined  by  the  combinator  ASSIGN 
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ASSIGN  *  [*F[Xn  v  f  t. 

n«FUNV-*ISADMISVAL(s(Myp«loc  FUNV), v<s)HSTORE(l,s, FUNV, v(s)),UU, 

ISINTYPE(n,v,f,sHSTORE(f,s,LOCOFVAR(n,f,s),v(s)L 

istopf(l)-*UU, 

ISFUNFR«,s(NEWFP(n,f,s))-»F(VARBNOTO(n1<,t),v,NEWFP(n1<1s)[s),UU]]. 

First  of  all  a  test  ts  done  to  see  whether  the  location  to  be  assigned  is  FUNV,  re  if  we  are  assigning 
the  value  to  a  function  identifier  in  a  function  activation  (see  3.2  1.3).  In  this  case  if  the  typeloc  FUNV 
is  prccent  in  the  current  frame  and  the  value  v  matches  with  its  content,  the  combinator  STORE  stores 
v(s)  in  FUNV  (see  appendix  3.9).  Otherwise  ASSIGN  returns  the  undefined  store.  If  n  is  not  FUNV, 
then  the  current  frame  is  checked.  If  n  has  teen  declared  in  it  and  the  value  v  matches  with  its  type 
then  the  assignment  takes  place  A  type  mismatch  ma*es  the  assignment  to  return  the  undefined 
store  If  n  is  not  local  to  the  current  frame,  it  may  be  a  name  parameter  or  a  free  variable  for  that 
frame.  In  both  cases  ASSIGN  applies  recursively  with  a  mechanism  quite  similar  to  FETCHV  (see 
3  2.1.2)  The  only  difference  is  that  here  a  test  is  done  by  ISFUNFR  to  see  if  the  assignment  may  cause 
a  side  effect  in  a  function  activation. 

ISFUNFR  *  [«cF.[X<  s  nf.  ISLOCAL(FUNV ,*(«))-»  FF,pred  f*n<  -»  TT,F(pred  f,6,n«)]]. 

ISFUNFR  checks  if  any  frame  between  those  pointed  to  by  <  and  nf  is  a  function  frame,  i.e.  if  FUNV  is 
local  to  it. 

The  auxiliary  combinator  ISINTYPE: 

ISINTYPE  •  [Xv  v.l  f  s.ISLOCAL (typeloc  NAMOFVAR(v),S(f)MSADMISVAL(TYPOFVAR(v,f,s),v.l(*)),FF]. 

evaljates  to  true  if  th»  variable  v  is  local  to  the  frame  s(f)  and  the  value  val  is  compatible  with  its 
type.  It  evaluates  to  false  if  v  is  not  local  to  t{i)  and  to  undefined  if  a  type  mismatch  occurs.  The 
definition  of  the  combinators  used  in  ISINTYPE  may  be  found  in  appendix  3. 7,-9. 

3.3. 1.3  Procedure  Statement 

When  a  procedure  is  activated,  its  formal  arguments  are  bound  to  the  actual  arguments  in  a  new 
frame  obtained  by  increasing  the  current  frame  pointer  by  I  In  such  frame  a  location  textloc  is 
created  whose  content  is  the  statement  part  of  the  activated  procedure,  and  a  location  alnk  is  created 
containing  the  pointer  to  the  frame  where  the  procedure  has  been  declared 

By  looking  at  the  definition  of  MS  given  in  3  3  we  see  that,  when  a  procedure  statement  is  executed, 
the  auxiliary  combinators  PROCr'AL,  PROCBODY,  PROCDECl  are  used.  They  are  defined  in  appendix 
3.8  and  are  used  for  fetching  the  formal  argument  list,  the  declaration  part  and  the  statement  part  of 
the  activated  procedure. 

The  set  up  of  the  new  frame  and  the  binding  of  the  parameters  is  done  by  MPB; 

MPB  *  [Xfi  ••  f  s  n.BIND(l«,»a,succ  f,MAKFRAME(PROCBODY(n,<,s),PFLNK(n,f,s),succ  <,*))] 

MAKFRAME  sets  up  a  new  frame  and  creates  the  locations  textloc  and  »lnk  in  it  At  the  end  of  the 
procedure  activation  such  frame  is  deleted  by  CLEAR 

CLEAR  *  [Xf  s  U.(fl«fMJU,s(fl)] 
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CLEAR  makes  it  explicit  that  the  local  variables  of  the  procedure  frame  are  no  longer  in  the  stoie 

The  bindings  of  the  parameters  in  a  procedure  activation  is  the  same  as  that  of  a  function 
activation  It  is  defined  by 

BIND  a  [ocF  [Xfa  aa  f  s 

iseof  fa  -»  (issof  aa  -»  s,UU), 

isparameterffslof  fa)  -*F(rmdof  fa.rmdof  aa,f,MKBINDING(fs(of  fa.fslof  aa,fts)),UU]]. 

Corresponding  parameters  in  the  two  lists  are  bound  by  MKBINDING.  If  the  two  lists  have  different 
length  the  binding  results  in  an  undefined  store.  PASCAL  allows  procedures  without  parameters.  In 
such  case  the  abstract  syntax  for  the  two  parameter  lists  is  the  empty  list  EOF. 

The  MKBINDING  combinator  is  defined  as 

MKBINDING  <  [Xfa  aa  f  s. 

isvarp(fa)  -*  TYMATCHIfa.fypeloCpaa^.s)  -* 

CREALOC(f,s,bindloc,namof  fa,EXPRFORV(aa)),UU, 
isvalp(fa)  -*  A$SIGN(namof  fa,MEXPR(aa,f),f, 

CREAV(f,namof  fa.fypof  fa,CRNTF« ,s),s)>, 
isfunp(fa)  -*  TYMATCHda.fypfunloe^a.f,*)  -♦ 

CREAF(f,namo«  fa,FUNCDEF(aa,f,s),iypof  fa,CRNTF(f,s)pPFLINK(aa,f .sJ.sJ.UU, 
isprocp (f a )— *  CREAPff.namof  fa.PROCDEF (aa,f ,s),PFLINK(aa,f,s),s),UU]. 

If  the  formal  parameter  fa  is  a  variable  parameter  (i.e.  a  parameter  passed  by  name)  then,  if  its  type 
matches  the  type  of  the  actual  parameter  aa,  a  binding  location  bindloc  (namof  fa)  is  created.  Its 
content  is  the  EXPRFORV(aa).  If  aa  has  subscripts  they  must  be  evaluated  when  the  binding  takes 
place  (see  Wirth  1971).  This  evaluation  is  performed  by  EXPRFORV  which  substitutes  a  numeral  for 
the  value  of  each  subscript 

The  test  on  the  type  matching  between  formal  and  actual  parameters  is  done  by  TYMATCH: 

TYMATCH  =  [Xfa  loc  aa  f  s  TYPEVALOypof  f a,CRNTF(f,s),s)=T YPEDEFdoc  aa.prcd  f,s)J. 

The  type  identifier  associated  with  the  formal  argument  is  evaluated  (by  TYPEVAL)  in  the  frame 
where  the  procedure  has  been  declared.  The  pointer  to  it  is  retrieved  by  CRNTF.  We  have  in  fact 
chosen  to  evaluate  the  type  associated  with  the  formal  arguments  of  a  procedure  when  it  is  activated 
and  not  when  it  is  declared  The  type  of  the  actual  argument  is  fetched  from  the  store  by  the 
TYPEDEF  combinator  in  the  location  typeloc  aa  or  t/pfunloc  aa  depending  on  whether  fa  is  a  variable 
or  function  parameter.  All  these  auxiliary  combinators  are  defined  in  appendix  3.8  Here  we  only 
describe  TYPEVAL- 

TYPEVAL  a  [ocF  [Xn  «  s 
isbasetyp®  n  -»  n, 

isarspec  n  -*  mkarsp*c(F(arlimof  n,f,s),F(fypelof  n,f,s)), 
islyppart  n  -*  iseof  n  -»  n, 

ispair  n  -»  mkpair (F (fstof  n,f,s),F(rmdo<  n,f,s)),UU, 

ISLOCALdypeloe  n,s(f)HF(s(f,lypeloc  n),f,s), 
islopf  <  -»  UU,F (n, CRNTF (f,s),s)]]. 

If  the  type  n  being  evaluated  is  a  base  type,  i.e.  integer  or  subrange,  then  TYPEVAL  evaluates  to  it  If 
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n  is  an  array  speofication,  then  both  the  types  of  its  subscripts  and  the  type  of  its  elements  are 
recursively  evaluated.  The  types  of  the  subscripts  of  an  array  are  given  as  a  list  of  subranges.  This 
list  satisfies  the  predicate  islypparl,  so  each  one  of  its  elements  is  recursively  evaluated  Finally,  if  the 
type  being  evaluated  is  a  type  identifier  defined  in  the  current  frame,  then  TYPEVAL  applies 
recursively  to  its  definition  If  the  type  definition  is  not  found  in  the  current  frame,  then  the 
appropriate  frame  is  searched. 

If  a  formal  parameter  f;  is  passed  by  value,  then  a  variable  la  is  declared  in  the  current  frame  by 
CREAV  (see  3.1.2).  Its  type  is  evaluated  by  TYPEVAL  in  the  appropriate  frame  and  stored  into  the 
location  typaloc  la.  The  value  of  the  actual  parameter  aa  is  then  computed  by  MEXPR  and  assigned  to 
(a.  ASSIGN  checks  whether  or  not  the  types  of  la  and  aa  are  compatible  (see  3.3.1  2). 

If  the  formal  parameter  la  is  a  function  parameter  and  the  type  of  fa  matches  with  thac  of  aa.  a 
function  la  is  declared  in  the  current  frame  by  the  combinator  CREAF  (see  3.1  3).  The  type  of  this 
function  is  the  type  of  la  evaluated  by  TYPEVAL  in  the  appropriate  frame.  In  its  acclnk  location  the 
content  of  the  acclnk  location  of  aa  is  stored.  The  text  of  the  actual  argument  is  retrieved  by 
FUNCDEF,  its  acclnk  by  PFLINK  and  its  type  is  evaluated  by  TYPEVAL  in  the  usual  way. 

If  the  formal  parameter  la  is  a  procedure  parameter  a  procedure  is  declared  in  the  current  frame 
by  CREAP.  In  the  acclnk  of  such  procedure  the  content  of  the  acclnk  location  of  the  actual  parameter  is 

stored. 

Since  the  combinators  used  for  binding  formal  and  actual  parameters  are  those  used  in  declarations 
(see  3.1.2.-3).  an  undefined  store  is  returned  if  the  reserved  identifier  FUNV  is  used  as  formal 
parameter  (see  3.2.1. 3  for  a  discussion  on  the  use  of  FUNV).  Ftom  the  definition  of  MKBINDING  it  is 
also  evident  that  FUNV  cannot  be  used  as  an  actual  parameter  since  both  EXPRFORV  and  MEXPR 
return  an  undefined  result  if  applied  to  FUNV  The  auxiliary  combinators  used  by  MKBINDING  test, 
by  ISPRESENT,  the  presence  of  identifiers  in  a  frame.  It  follows  that  an  identifier  cannot  appear  twice 
as  formal  parameter  and  in  the  declaration  part  of  a  procedure. 

Procedures,  as  well  as  functions  (see  3.2.13),  cannot  be  executed  recursively  if  they  declare  a 
procedure  or  have  a  formal  procedure  parameter  with  the  same  name. 

As  noted  for  functions,  a  procedure  may  also  have  itself  as  actual  argument.  Even  though  LCF  is  a 
typed  logic,  we  avoid  type  conflicts  by  passing  texts,  and  not  functions  as  parameters. 

3.3.1. 4  Read  Statement 

PASCAL  has  no  read  and  write  statements.  We  have  introduced  them  for  defining  the  semantics  of 
the  input  and  output.  In  Wirth  1972  a  standard  procedures,  read  and  write,  are  introduced  for 
handling  the  input  and  output. 

As  said  in  2  2  the  data  to  be  inputed  is  stored  into  the  filaloe  INP  location  of  the  store  by  the  PASCAL 
function  Whenever  the  value  of  a  variable  has  to  be  inputed,  it  is  read  from  the  buffer  INP  by  the 
READ  function 

READ  *  (Xn  f  s.lSFUNFR(f,s,0)-*ASSIGN(n,MEXPR«siof(IBUFFER  s),f),f, 

STORE(0,s.f iloloc  INP,rmdof(IBUFFER  s))),UU]. 
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A  test  is  done  to  see  If  the  read  statement  is  executed  during  a  function  activation,  in  this  casr  the 
result  of  READ  is  undefined.  Otherwise  its  result  is  a  new  store  where  the  first  element  of  the  input 
buffer  has  been  removed  and  its  value  has  been  assigned  to  the  variable  being  read 

3.3  1.5  Write  Statement 

The  results  produced  by  a  program  are  stored  into  the  fildloc  OUT  location,  where  they  are  eventually 
retrieved  by  the  OUTPUT  combmator  (see  22).  The  write  statement  puts  into  the  buffer  the  numeral 
of  the  value  of  the  varia  ale  to  be  outputed. 

WRITE  *  [Xn  f  s.lSFUNFR(f,s,8)->STORE(0fs,fileloc  OUT,mkpair(mknumconst(FETCHV(n,f,s)), 

OBUFFER  s )),UU]] 

As  with  the  read  statement,  it  is  forbidden  to  write  during  a  function  activation 


3.3.2  Structured  S'atements 

The  structured  statements  included  in  our  verson  of  PASCAL  are. 

1)  the  conditional  statement  in  its  two  forms:  if-thru  and  if-then-ehe., 

2)  the  repetition  statements  while  and  repent, 

3)  the  for  statement  in  its  two  forms:  fnr-to  and  for-downto. 

We  have  not  included  the  rote  and  the  with  statements  defined  in  Wirth  1971,  1972  since  they  do 
not  seem  very  relevant  to  the  integer  arithmetic  part  of  PASCAL.  In  Wirth  1971,  1972  the 
compound  statement  is  also  included  in  the  list  of  structured  statements.  In  our  description  of 
PASCAL  the  compound  statement  does  not  appear  since  the  hecin,  end  delimiters  are  not  present  in 
the  abstract  syntactic  form  of  a  program  The  compound  statement  in  its  abstract  syntactic  form  is  a 
list  of  statements  assembled  by  the  syntactic  constructor  mkempad  and  ending  with  the  symbol  ES. 
The  semantics  of  the  compound  statement  is  defined  by  MS  whicl  establishes  the  flow  of  the  control 
through  the  statement  part  of  the  program  text. 

3.3.2  1  Conditional  Statement 

The  conditional  statement  in  PASCAL  has  two  forms:  if-then  and  if-then-elsc.  In  the  abstract 
syntactic  form  the  conditional  statement  always  has  an  else  part,  possibly  it  reduces  to  the  empty 
statement  ES 

The  semantics  of  the  conditional  statement  is  defined  by  the  combmator  CCND: 

COND  s  [Xq  <  g  s.(q(s)-M(s),s(s))]. 

The  test  of  the  conditional  is  evaluated  in  the  store  where  the  conditional  statement  is  executed  The 
conditional  returns  the  then-part  or  the  else-part  evaluated  in  this  store,  depending  on  the  value  of 
the  test 

Goinfe,  back  to  the  definition  of  MS  given  in  ?.3.  we  see  that  if  the  first  statement  of  the  text  in 
execution  is  a  conditional,  its  test  is  evaluated  by  the  MBEXPR  combmator  and  then  MS  applies 


The  Semantics  of  PASCAL  in  LCF 


20 


recursively  to  the  text  resulting-  from  appending  the  then-part  or  the  else-part  of  the  conditional  to 
the  remaining  statements.  The  appond  function,  defined  in  appendix  2.5  corresponds  to  the  ordinary 
appending  function  for  lists. 

If  a  goto  statement  is  executed  within  a  branch  of  a  conditional,  then  the  execution  goes  on  with  the 
text  furnished  by  the  segm  function.  If  a  jump  into  a  branch  of  a  conditional  is  done,  then  the  text 
to  be  executed  next  consists  of  all  the  statements  between  the  first  occurrence  of  the  label  to  jump  to 
and  the  end  of  the  branch  of  the  conditional,  appended  to  the  rest  of  the  program  This  text  is  the 
result  of  the  s«  -i  (unction  defined  in  3.3. 1.1. 

3.3.2.2  While  and  Repeat  Statements 

The  while  statement  is  a  repetition  statement  whose  abstract  syntax  is: 
mKwhil«(t«st,body). 

body  is  repeatedly  executed  until  tost  becomes  ‘alse  The  semantics  of  the  while  statement  as  given  in 
MS  (see  3.3)  can  be  explained  as  follows:  trst  is  evaluated,  if  its  result  is  true,  then  MS  applies 
recursively  to  body  appended  to  the  wHIe  statement  itself  and  to  the  remaining  statements  in 
execution  If  the  test  fails,  MS  applies  to  the  remaining  statements. 

Wirth  1971  says  that  in  PASCAL,  for  all  e  and  S  the  'wo  statements 

wltilr  e  do  S 

and 

if  e  then  /login  S;  while  e  do  S  end 
are  equivalent.  We  prove  this  true  for  our  semantics  (see  4.4). 

The  repeat  statement  is  similar  to  the  while  statement.  The  only  difference  is  in  that  the  repeat  first 
executes  its  body  and  then  performs  the  test  to  see  whether  to  go  on  or  stop.  The  semantics  of  the 
repeat  statement  is  defined  in  MS  (see  3.3).  MS  applies  recursively  to  the  body  of  the  repeat, 
appended  to  a  conditional  (specifying  whether  or  not  the  repeat  must  be  executed  again),  appended 
to  the  remaining  statements  in  execution. 

We  have  also  proved  the  equivalence  described  in  Wirth  1971  for  the  repeat  statement,  i.e  for  all  < 
and  S  the  two  following  statements  are  equivalent: 

repent  S  until  ( 


and 


begin  S,  if  -e  then  repent  S  until  (  end 

In  Weyhrauch  and  Milner  1972  and  m  Aiello  and  Aiello  1974  a  WHILE  combinator  w,  s  introduced 
for  defining  the  semantics  of  the  while  statement; 
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WHILE  *  [ocF  [XI  b  COND(t,b&F(t,b),ID)]]. 

It  cannot  be  used  here  since  a  goto  statement  can  stop  the  execution  of  the  body  of  the  while.  We 
can  prove  that  the  definition  of  the  semantics  for  the  while  statement  given  in  MS  reduces  to  the 
above  semantic  combinator  when  the  body  of  the  while  is  goto  free  (see  4.3). 

The  language  described  in  Weyhrauch  Milner  1972  had  no  repeat  statement  The  semantics  for  the 
repeat  statement  was  described  in  Aiello,  Aiello  1974  by  the  combiner  REPEAT; 

REPEAT  ^  [ocF.JXb  t.  b®COND(t,F(b,t),ID)]]. 

It  is  similar  to  the  WHILE  combinator  described  above  and  the  same  considerations  concerning  the 
presence  of  goto’s  hold  for  it. 

If  a  goti)  statement  is  executed  within  the  body  of  a  while  or  repeat  statement,  then  the  execution  of 
the  rep’tition  statement  is  stopped  and  the  text  to  be  executed  next  is  furnished  by  the  segm 
combinator  From  the  definition  of  segm  given  in  3.3.1,  we  see  that  when  a  goto  statement  jumps 
into  the  oody  oi  a  repeat  (while)  statement  the  piece  of  body  starting  from  the  first  occurrence  of  the 
label  is  appended  to  the  text  starting  from  that  repeat  (while)  statement.  This  means  that  the  part  of 
body  from  the  label  to  the  end  is  executed  and  then  a  test  is  dene  to  see  whether  or  not  the 
execution  of  the  repetition  statement  must  be  stopped  or  goes  on 

3. 3. 2.3  For  Statement 

In  PASCAL  the  for  statement  has  two  forms; 

for  i:~el  lo  (2  do  b; 

and 

for  i:*el  downio  e2  do  b ; 

In  both  cases  b  is  the  body  of  statements  which  is  repeatedly  executed,  and  i  is  the  variable  which 
controls  the  loop.  In  the  for-to  statement  it  is  increased  by  I  each  time  b  is  executed  In  the  for- 
downto  statement  it  is  decremented  by  I.  The  two  expressions  el  and  «2  will  be  referred  to  as  the 
initial  and  final  values  of  the  control  variable. 

The  abstract  syntax  for  the  two  forms  of  for  statements  is  defined  by: 

mkforto(i,el  ,e2,b), 

mkfordn(i,el  ,#2,b). 

Their  semantics  is  defined  in  MS.  A  test  is  done  to  check  if  the  value  of  the  control  variable  i  is 
equal  to  the  final  value  e2  The  test  is; 

fortest  =  [Xx  .isfortofxHmkreUlsaq.lboIM.ubofMLisfordnUHmkrcllgroq.uboflxklbofMLUU). 

If  fortest  evaluates  to  TT,  the  initial  value  el  is  assigned  to  the  control  variable  i,  then  the  meaning 
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function  MS  applies  10  ne  body  of  the  for  statement  appended  to  the  text  assembled  by  the 
combinator  fortoup  (fordnup)' 

fortoup  ■  [\x  .mkcmpnd(mkforto(indexof(fstof  (x)),mk«xpr I  (plus  1  ,ind*xof(fsiof  (x))), 
ubofOstofMLbodyofUitofMM.rmdofU))], 

fordnup  «  [\x  .mkcmpnd(mkfordn(ind*xof(fstof(x)),mk#xprl  (minus  I  ,ind*xol(f*to»(x))), 
IbofffstofWLbodycf'fstofMH.rmdofU))] 

fortoup  (fordnup)  updates  the  initial  value  of  the  for  loop  by  substituting  i*l  (i-l)  for  i. 

We  have  chosen  to  def  ne  the  for  in  terms  of  the  algorithmic  equivalences  given  in  Wirth  1971,  i.e. 
for  all  i,  el,  e2  and  5  the  statement: 

for  i:mel  to  e2  do  S 

is  equivalent  to 

if  el<e2  then 
bo  gin  i:mel;S; 

for  i:-succ(i)  to  e2  do  S 

olid 

and  the  statement 


for  i:~tl  doumto  e 2  do  S 

is  equivalent  to 

if  el>e2  thou 
begin  i:-el;S; 

for  i;-pred(i)  to  e2  do  S 
end 

We  have  imposed  no  restrictions  on  the  fact  that  the  values  of  i,  el  and  c2  are  changed  by  S  or  by 
the  for  statement  itself,  or  on  the  jumps  into  or  out  from  the  body  of  a  for  statement.  The  value  of 
the  control  variable  at  completion  of  the  for  has  the  last  value  assumed,  namely  the  value  it  had 
after  the  last  execution  of  S.  This  interpretation  of  the  for  statement  is  different  from  the  description 
of  the  FASCAL  for  statement  as  given  in  Wirth  1971,  1972  and  in  Hoare  and  Wirth  197?.  The 
definitions  given  in  these  three  papers  are  indeed  different  from  each  other.  Our  choice  has  been 
motivated  by  the  fact  that  we  wanted  the  semantics  of  the  for  statement  to  be  as  smooth  as  possible 
and,  at  the  same  time,  we  wanted  to  make  it  less  ambiguous  then  Wirth  1972.  The  definition  of  the 
for,  given  in  terms  of  the  above  algorithmic  equivalences  in  Wirth  1971,  was  changed  in  Wirth 
1972,  following  me  suggestions  made  in  Hoare  1972.  In  order  to  leave  the  implementer  more 
freedom,  the  following  equivalences  are  required  in  Wirth  1972: 

for  t:mel  to  e2  do  S 

is  equivalent  to 
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5,  i.-succ(i);  5;  ...  i:-f2,  S 


and 

for  i:~el  doumto  1 2  dn  S 
is  equivalent  to 


t  «<•/,  S;  i  =pred(i);  S;  ...  i:~t2;  S 


These  definitions  stem  ambiguous  to  us:  what  happens  if  el>e2  in  the  for-to  statement? 

The  third  definition  of  the  PASCAL  for  statement  is  given  in  Hoare  and  Wnth  1973.  This  is 
closer  to  that  given  in  Wnth  1972,  but  not  the  same.  It  is  given  in  axiomatic  form: 

(a<x<b)  a  P([a..x))  { 5 }  P([a..x)) 


P([\)  { for  x:*a  to  b  do  S}  P([fl..6]) 
(a<x<b)  a  P((x..b))  {5}  P([x.b)) 


P({])  { for  x:*b  doumto  a  do  S)  P([a..b]) 

It  is  written  in  the  formalism  proposed  by  Home  1969,  where  PjQJR  means  that  if  P  and  R  are 
predicates  and  P  is  true  before  the  p'pCution  of  die  body  of  statements  O,  and  ^terminates,  then  R 
is  true  after  the  execution  of  Q.  ]  denotes  the  interval  jx|a<x<b},  [a,b)  denotes  the  inteival 
{x|a<x<b},  and  so  on.  This  rule  was  u;ed  in  Hoare  1972  for  characterizing  the  correctness  of  the  for 
statement  Apart  from  the  far  ^at  the  description  of  the  rule  given  in  Hoare  1972  and  that  given  in 
Hoare  and  Wirth  1973  are  ’tent,  we  do  not  agree  with  it.  In  fact  it  leaves  unspecified  what 
happens  when  the  for-to  sta  nt  is  executed  with  the  initial  value  greater  then  the  final  value.  It 
seems  to  us  that  any  defmu.-n  which  leaves  this  ambiguous  cannot  serve  as  a  satisfactory 
specification  of  the  meaning  of  the  for  statement.  In  particular  »t  cannot  be  used  to  prove  general 
theorems  about  the  for  statement.  Consider  for  example  an  implementation  of  PASCAL  in  which  if 
b<a  in  one  of  the  above  for  statements,  then  the  body  of  statements  5  is  executed  14  times!  This 
implementation  satisfies  the  above  axioms,  but  is  certainly  strange 

In  Wirth  1971,  1972  nothing  is  said  about  the  behavior  of  the  goto.,  with  respect  to  the  for 
statement.  Hoare  and  Wirth  197?  do  not  deal  with  goto’s.  In  our  semantic  definition,  if  a  goto 
statement  is  executed  within  the  body  of  a  for  statement,  then  the  execution  of  the  repetition 
statement  is  stopped  and  the  text  returned  by  segm  is  executed  next  From  the  definition  of  segm  we 
see  that  if  a  jump  info  the  body  of  a  for  statement  is  executed,  then  segm  returns  the  piece  of  body 
starting  from  the  first  occurrence  of  the  label  to  jump  to,  appended  to  the  piece  of  abstract  syntax 
returned  by  the  fortoup  or  fordnup  combinators. 

If  a  jump  into  the  body  of  a  for  statement  is  executed  we  distinguish  between  two  cases:  I)  me  jump 
is  from  one  point  to  another  point  of  the  body  of  the  same  for  statement.  In  this  case  the 
computation  goes  on  with  the  control  variable  having  the  ament  value.  2)  the  jump  is  from  a  point 
of  the  program  outside  the  for  statement.  In  such  case  the  computation  may  result  in  the  undefined 
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store  accordingly  to  whether  or  not  the  control  variable  has  been  assigned  a  value  prior  to  the 
execution  of  the  jump.  In  fact  the  updating  combinators  lorloup  and  lordnup  replace  i»l  and  i-l  for 
•  I  in  the  for  statement,  so  it  evaluates  to  UU  if  the  control  variable  has  not  yet  been  assigned  a 
value 

Haberman  1973  dislikes  the  possibility  of  jumping  into  a  for  statement.  We  have  allowed  such 
jumps,  thus  a  for  loop  may  be  initialized  from  outside  and  started  by  a  jump  This  seems  reasonable 
since  PASCAL  has  no  block  structure,  so  the  control  variable  of  a  for  statement  has  to  be  declared 
in  the  declaration  part  of  the  text  and  may  be  given  a  value  independently  of  the  for  statement 
Furthermore,  since  the  control  variable  is  not  local  to  the  for  statement,  we  do  not  see  any  reason  for 
leaving  it  undefined  after  the  execution  of  the  for  statement,  as  required  in  Wirth  1972.  Nothing  is 
said  at  this  regard  in  Wirth  1971  and  in  Hoare  and  Wirth  1973.  We  do  not  agree  that  a  perfectly 
behaved  statement  should  leave  an  undefined  value  in  a  location  which  has  been  declared  and 
assigned  a  value.  It  also  leaves  ambiguous  what  happens  to  the  control  variabl;  if  a  goto  stops  the 
execution  of  the  for  loop. 

Our  semantics  doesn’t  check  to  see  if  the  control  variable,  the  initial  value  or  the  final  value  are 
modified  during  the  execution  of  the  for  statement.  This  makes  our  for  statement  similar  to  the 
while  statement  Since  the  control  variable  is  not  a  dummy  variable  of  the  loop  there  is  no  reason 
for  it  to  be  treated  differently  from  any  other  variable  Wirth  1971,  1972  and  Hoare  and  Wirth 
1973  are  discordant  about  the  requirements  on  such  modifications.  Moreover  it  is  our  opinion  that 
checking  for  them  is  very  difficult  and  is  unlikely  to  be  done  in  any  current  implementations  of 
PASCAL.  Consider  for  example  a  program  where  an  integer  variable  i  is  declared  which  also 
declares  the  following  procedure; 

procedure  A(jji.integer) 
for  i.*j  to  k  do 

if  i then  A(k*lj) 
ehe  A(j*IJi); 

Note  that  in  this. program  the  control  variable  is  changed  by  the  recursion  of  the  procedure  A,  not 
by  an  assignment  statement. 

A  final  point  regarding  our  semantics:  as  with  the  while  and  repeat  statements,  if  a  text  is  goto-free 
the  semantics  of  the  for  statement  can  be  defined  by  the  following  two  combinators: 

FORTO  *  [ocF.[\i  •!  *2  b  f.  COND(MBEXPR(mkrel(Isoq,el ,«2),f),ASSIGN(i,MEXPR(«l 
F(i,mk«xpr I  (plus  I  ,i),«2,b,f),ID)]]; 

FORDN  *  [ocF.[Xi  *1  e2  b  f.  COND(MBEXPR(mkrel(greq,el ,e2),f),ASSIGN(i,MEXPR(el ,f),l)®b6> 

F(i,mkexprl  (minus  lli),«2,b,f),ID)j]; 

The  equivalence,  in  the  goto  free  case,  between  the  definition  of  the  semantics  of  the  for  statement 
given  in  MS  and  that  given  by  the  two  above  combinators,  can  be  proved  easily  (see  4  3) 


The  Semantics  of  PASCAL  in  LCF 


25 


SECTION  4  PROPERTIES  OF  THE  SEMANTICS 

In  this  section  we  discuss  some  general  properties  of  the  interpretation  of  PASCAL  in  LCF  We 
have  proved 

1)  the  meaning  function  MS  is  strict  on  the  store,  i.e.  for  any  statement  st  and  any  franiepomter  I, 

MS(st,f(UU)'UU, 

2)  for  goto-free  prognms,  MS  is  a  homomorphism  with  respect  to  the  constructor  mkcmpnd,  i.e. 
Vf.M$(mkcmpnd(a,b  ,f >=MS(a,f )®MS(b,f ). 

3)  MS  reduces  to  a  simpler  function  for  goto-free  programs.  New  combinators  defining  the 
semantics  of  the  epetition  statements  ire  given. 

4)  all  the  equivalences  about  repetition  statements  given  in  Wirth  1971  hold  in  our  semantics. 

5)  some  miscellaneous  theorems  about  MDEC,  MDEF,  MS 

Section  4.1  The  strictness  of  MS  on  the  More 
The  mam  theorem  of  this  section  is 
Vst  f  MSIst.f.UUJsUU 

We  do  not  show  the  proof  here  as  it  is  a  single  LCF  simplification  using  the  lemma 
Vt  a  b.{t— *a,b)(UU)=(t-*a(UU)Ib(UU)) 

The  main  theorem  should  not  be  regarded  as  trivial  however,  as  it  requires  208  substitutions. 
Without  the  LCF  simplifier,  this  proof  would  have  been  over  1000  steps  long  This  is  an  important 
theorem  because  it  shows  that  our  interpretation  of  statement'  behaves  correctly  with  respect  to  the 
termination  of  computations. 

Consider  the  following  program 

ror  n.integer 
begin 
l:  goto  1, 
n:~l. 
end 

This  program  fails  to  terminate  To  us  it  seems  that  the  only  reasonable  interpretation  of  this 
program  must  be  the  undefined  function.  If  the  meaning  function  is  not  strict,  it  may  happen  that 
the  assignment  of  I  to  n  builds  up  a  store  in  which  n  has  value  I  Suppose  we  were  to  choose  the 
most  obvious  interpretation  of  assignment,  i.e  if  the  above  program  is  being  executed  in  a  store  s, 
and  a  frame  whose  framepointer  is  <  then  the  meaning  of  the  assignment  statement  in  the  example  is 
a  npw  store  si 
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si  *  [Xfr.fr«f-*[Xm.m«n-*l ,s(<,m)](s(fr,m)3, 


so 


si  (f)  *  [Xm.m«n-*l,s(f,m)]. 

This  new  store  has  the  unfortunate  property  that  even  if  «*UU,  we  still  have  sl(f,n)*l.  It  is  thus  not 
undefined 

The  desire  for  the  interpretation  of  a  program  to  be  an  extensionally  given  function  on  the  store 
and  composition  of  these  functions  to  correspond  to  executing  one  program  after  another,  means  that 
an  interpretation  which  is  strict  on  the  store  is  the  only  one  that  makes  sense.  In  Hoares  axiomatic 
treatment  this  problem  goes  away  but  the  price  is  that  every  statement  that  you  can  prove  about  a 
program  is  conditional  on  its  termination.  In  the  above  case  one  proves  the  sentence.  If  the 
program  terminates  then  n»l" 

Because,  as  already  said,  the  proof  is  a  single  step  we  do  not  give  it  here.  Instead  we  will  explain 
why  for  our  semantics  ASSIGN  is  strict  on  the  store.  The  W  represent  some  arbitrary  combinator. 

ASSIGN  *  [Xn  v  f  s.n*FUNV-ISAOMISVAL<s<f,typeloe  FUNV),v(s))-  ***)IS!NTYPE(n,v,f,sH  *♦*,***] 

So 

ASSIGN(n,v,f,UU)  *  n.FUNV-*ISADMISVAL{UU,vlUU)H  #**,UU,l$INTYPE(n,v,f,UUH  ***,***] 

ISADMiSVAl  asks  if  a  value  is  of  an  admissible  lype.  UU  is  not  even  a  type,  no  less  admissible,  so 
ISADMISVAL  returns  UU. 

I S INTY PE ( v ,v«lf« ,UU )>l S LOCAL (ty p«loe  NAMOFVAR(v),UU)HSADMISVAL(TYPOFVAR{v,I,UU),v*l{UU)),FF] 
ISLOCALfloe.UU)  *  UU«UNDEF-*FF,TT 

But  for  any  X.  UU=X  is  just  UU  so  l$LOCAL(loc,UU)*UU.  This  is  the  central  point  of  the  entire  strictness 
proof.  Looking  ui  a  location  in  a  defined  store  in  an  existing  frame  is  not  undefined  if  that 
location  has  not  been  created.  Stores  are  constructed  in  such  a  way  that  we  can  test  if  it  is  defined 
and  no  assignment  is  made  if  it  isn’t.  This  check  is  done  by  ISLOCAL,  which  returns  UU  if  the  frame 
is  undefined.  The  proof  is  completed  by  making  the  correct  substitutions. 

Other  theorems  about  strictness  appear  in  section  4.5. 


Section  4.2  Properties  of  MS  for  goto-free  programs 
A  goto-free  program  is  defined  by  the  following  predicate  : 

isgototraa  *  [ocF.[X  s  . 

isgoto  s  -*  FF, 
issingla  c  -*  TT, 
islabstat  s  -*  Ffstatmof  s), 
isiter  s  Ffbodyof  s), 


jn^p^^lIRPPPililiP^p 
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iscond  t  ■*  F(thenof  s)  a  flilsiol  s); 
iscmpnd  s  -*  F(fstof  s)  A  F(rmdof  s),UU]]t 

where  iningla  and  isiter  are  predicates  satisfied  by  the  simple  and  the  repetition  statements 
respectively  (see  appendix  2.4)  The  main  theorem  about  goto-free  programs  is: 

V  S  P  f.i*gotofr**(S):.i*gotolr*«(P)::  MS(app«nd(S,P),l)  *  MS(S.f)  •  MS(P,U. 

It  states  that  if  S  and  P  are  texts  without  any  goto  statement,  then  the  result  of  the  application  of  MS 
to  the  concatenation  of  them  is  the  same  as  the  functional  composition  of  the  application  of  MS  to 
each  of  them.  The  proof  of  this  theorem  is  based  on  a  case  analysis  on  the  first  element  of  S.  We 
have  not  included  it  in  the  paper  as  it  is  rather  long  even  if  very  simple.  We  didn’t  find  any  proof 
by  induction  on  isgolofree,  so  we  proved  it  by  induction  on  MS.  To  do  this  the  two  following  lemmas 
are  to  be  proved: 

VS  P  f.isgotofre«(S)::isgotofree(P)::MS(append(S1P)1f)cMS(S1f)0MS(Plf) 

VS  P  f.isgofofre«(S)::isgotofree(P)::MSl3,f).':MiiP,f)it.15(append(S,P),f) 


In  section  4.1  it  has  been  noted  that  the  pioof  ot  the  strictness  of  MS  on  the  store  depends  on  a 
theorem  about  conditional  expiessious.  For  piovuig  :he  above  lemmas  with  a  similar  proof  we 
needed  the  following  theorem  about  conditional  expressions: 

Vt.<t— *»,b)  C  (1-*d,f)  ASSUME  acd,  bcf. 

Unfortunately  the  current  version  of  the  LCF  conditional  simplifier  doesn’t  handle  sentences  of  the 
form  AcB  as  simplification  rules,  even  though  in  this  case  no  specific  property  of  the  symbol  c  is 
involved. 

The  above  homomorphism  theorem  is  analogous  to  the  Hoare’s  composition  rule  for  statements, 
valid  for  goto-free  programs  This  theorem,  as  well  as  Hoare’s  rule  is  not  valid  in  general.  Consider 
the  following  example: 


«:»/: 
gntn  I; 

I: 

the  corresponding  ahstiact  syntax  is: 

P  £  mkcmpnd(mkass(a,mknumconsf  1 ), 
mkcmpnd(mkgoto  I ), 
mkcmpnd(mkass (a.mknumconst  3), 

mkcmpnd(mklabstat(l  .mkassta.mkbexpr  1  (plus  I  ,a)),ES)))) 

The  meaning  of  this  program  in  the  frame  specified  by  the  frame  pointer  f  is  defined  by  MS(P,f) 
The  validity  of  the  composition  rule  would  imply  the  following  equivalence: 

MS(P,f)  *  MS(mkcmpnd(mkasr.  (a.mknumconst  l),ES),f)« 

MS(mkempnd(mkgoto(l  ),ES),<)0 

M$(mkcmpnd(mkiSs(a,mknumconst  3),ES).f)» 
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MS(mkcmpnd(mklabotat(l  ,tnkass(a,mkbexprl  (plusl  ,a))),ES),l), 

winch  is  false  staitmg  from  a  stoie  where  a  is  declared  in  the  current  frame,  MS(P,0  returns  a  store 
where,  in  the  cu i rent  frame,  a  has  value  2,  while  the  .ight  hand  side  evaluates  to  a  store  where,  in 
the  current  frame,  a  as  value  4  The  light  hand  side  is  wrong,  since  by  interpreting  each  statement 
separately,  it  is  impossible  to  skip  a  piece  of  text  as  required  by  a  goto. 

In  the  next  section  we  consider  how  the  semantics  of  a  PASCAL  statement  part  is  simplified  when  it 
is  goto- free  Oi.r  semantics  deals  also  with  programs  where  the  composition  rule  is  not  valid  Hoare 
axiomatic  approach  to  the  definition  of  the  semantics  of  a  programming  language  relies  on  the 
validity  of  the  composition  rule,  so  it  cannot  easily  treat  programs  with  goto’s.  Hoare  and  Wirth 
197?  axiomatization  of  PASCAL,  for  instance,  doesn’t  define  the  goto  statement  The  Igarashi, 
London  and  Luckham  197?  VCGFN,  based  on  this  approach,  deals  only  with  backwards  goto's  and 
preseives  the  validity  of  the  composition  rule  by  considenng  indivisible  the  piece  of  program 
between  the  label  to  jump  to  and  the  goto. 


Section  *13  An  equivalent  meaning  function  for  goto-free  programs 

As  noted  in  the  description  of  repetition  statements  (see  ?.?.22,-3),  if  the  body  of  the  repetition 
statement  is  goto-free,  new  combmatois  may  be  defined  for  describing  then  semantics.  In  this  case 
the  semantics  defined  by  MS  is  the  same  as  that  defined  by  the  new  combmatois. 

The  pi  oofs  of  the  first  four  equivalences  are  quite  similar;  they  are  carried  out  by  subgoalmg  to  the 
two  goals  with  the  logical  symbols  c  respectively  All  these  pioofs  are  standard  and  could  be 
automated  by  enriching  the  features  of  the  current  LCF  system  In  appendices  4,5,6  we  have 
included  the  commands  and  the  printouts  of  the  proof  of  one  half  of  each  of  the  first  three 
equivalences.  The  fourth  is  analogous  to  the  third  one. 

The  pi  oof  of  the  equivalence  between  MS  and  MSGTFR  is  carried  out  by  proving  the  lemmas  with  c, 
o  respectively,  and  using  the  above  equivalences  for  repetition  statements.  A  long  case  analysis  on  S 
is  performed,  analogous  to  that  discussed  in  4.2.  Even  in  this  case  the  proof  could  become  very  short 
by  impiovmg  slightly  the  LCF  conditional  simplifier. 

1 )  VS  t  I  isgotofree(S)::  MS(rn.kcmpnd(mkwhile(l,S),ES),f)  -  WHILE(MBEXPR(t,<),MS(S,0) 

where  WHILE  ?  [ocF  [M  b  CONDO, b®F(t,b),ID)]] 

2)  VS  t  I  isgotof ree(S )::  MS(mkcmpnd(mkrepoal(S,l),ES),l) E  REPEAT(M$(S,f),MBEXPR(mkbexprl  (not,t),f)) 

where  REPEAT  =  [*F  [Xb  t  b®COND(t,F(b,l),IO)]] 

3)  VS  i  el  e2  f  .isgotof ree (S )::  MS (mkcmpnd(mkforto(ite I ,o2,S),ES),f)  *  F0RT0(i,el  ,o2,M$($,f),f) 

where  FORTO  *  [<*F.[\i  el  e2  b  I  CONO(MBEXPR(mkrel(l:eq,el ,e2 ),f ),ASSIGN(i,MEXPR (o  1 ,0,1) 

®b®F(i,mkoxprl  (plus  I  ,i  ),e2  ,b,f  ),I0 )}}; 

4)  VS  i  el  e2  I  .isgotofree(S)::  MS(mkcmpnd(mklordn(i,el ,e2 ,S ),ES ),f )  *  F0RDN(i,el ,e2,MS (S,f ),< ) 

where  FORDN  e  [*F[Xi  el  e2  b  <  CONDIMBEXPRtmkroKgroq.el ,e2),f),ASSIGN(ipMEXPR(el ,l),f) 
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®b®F(i,mk*xp’-l  (minus  l,  i),  •2,b,f),  ID))]; 
5)  VS  f  isgotofr*«(S)::  MS(S,0  1  MSGTFR(S.f) 


where 

M$GTFR=[ocF.[Xst  f. 

issmptyst  st  -*  ID, 
iscmpnd  st  -* 
is«mptyst(fstof  st) 
islabstat(fstof  st)— * 
isread(fstof  st)  - 
iswrite(fstof  st)  - 
isass  (fstof  st)  -i 
isproccall(fstof  st) 


iscond(fstof  st)  ■ 

iswhilo(fstof  st)  ■ 
isrepeat(fstof  st) 
isforto(fstof  st)  - 

isfordn(fstof  st) 


4  F(rmdof  st,f), 

F(statmof(fstof  st),t)©F(rmdo<  st,t), 

.  READ(namof(fstof  st),»)®f  (rmdof  st,t), 

WRITE(namof(fstot  st),f)®F(rmdof  st,t), 

ASSIGN(lhsof(fs»o<  st),MEXPR(rhsot(tstot  *t),0,f)®F(rmdot  st,f ), 
4[Xs.MPB(PR0CFAL(namof(fstof  st),f,s), 
actargof(fsto)  st),l,s,oafnof (fstof  st))]® 

[\s. MO(PROCDECL(namof (fstof  st),f,s),succ  t,s)]®  ,  . 

[Xs  F(PR0CB0DY (namof (fstof  st),',«),succ  f,t)]«CLEAR(suce  f)®F(rmdof  st,f), 

>  COND(MBEXPR(testof (fstof  st),f), 

F(»henof(fstof  st),f),F(elseof (fstof  st),f ))®F(rmdof  st,f), 

>  WHILE(MBEXPR(testof (fstof  st),*),F(bodyof (fstof  st),f))®F(rmdof  st,f), 

4  REPEAT(bodyof (fstof  st),MEXPR(mkboxprl  (not,testof(fstof  st)),f))®F(rmdof 
,  FORTO(indexof(fstof  st),lbof (fstof  st), 
ubof (fstof  st),bodyof (fstof  st),f)®F(rmdof  st,f), 

*  FORDN(mdexof(fstof  st),ubof (fstof  st), 

Ibof (fstof  st),bodyof (fstof  st),f)®F(rmdof  st,f ),UU,UU]] 


The  definition  of  MSGTFR  shows  how  our  semantics  simplifies  for  goto-free  programs  No 
manipulation  of  the  text  is  required,  every  statement  can  be  treated  independently  of  the  others 
som/combinators  as  fortest,  fortoup,  fordnup,  append  are  no  longer  necessity  The  seman  i 
combinators  for  repetition  statements  not  only  simplify  the  form  of  MS  but  also  the  pi  oofs  of 
properties  of  goto-free  programs.  In  fact,  in  the  general  case  proofs  by  induction  on  the  repetition 
statement  must  be  done  by  inducting  on  MS.  For  goto  free  programs  the  induction  can  be  directly 
done  on  the  appropriate  semantic  combinator  Hence,  only  properties  of  the  body  of  the  lepetition 
statements  and  not  of  the  whole  program  are  involved  The  structure  of  the  program  reflects 
directly  on  the  structure  of  the  proof  since  allows  to  factorize  it  into  easier  lemmas. 

In  section  5  I  two  different  piograms  which  compute  the  factorial  function  are  compaied.  In  the  first 
one  the  iteration  is  performed  by  a  while  statement,  in  the  second  one  by  a  backwards  goto.  The 
proofs  of  then  correctness  are  d.ffcirnt,  the  goto-free  case  is  more  straightforward  The  pi  oof  of  the 
correctness  of  the  goto  program  may  be  leduc.  d  to  that  of  the  goto-free  program  by  showing  that,  in 
general  a  while  loop  is  equivalent  to  an  appropriate  loop  controlled  by  a  conditional  goto  This 
example  shows  ,he  advantage  of  a  formalism  which  allows  to  prove  general  properties  of  the 
language  and  the  necessity  of  creating  the  right  environment  of  theorems  about  the  programming 
language  to  greately  simplify  the  proofs  of  properties  of  piograms 


Section  4.4  Equivalences  for  repetitive  statements 

In  giving  an  interpretation  of  PASCAL  in  LCF  our  aim  was  to  be  as  close  as  possible  to  the 
informal  description  given  in  W.rth  1971.  For  this  reason  we  proved  most  of  the  properties  of  the 
statements  that  are  mentioned  in  that  paper.  The  LCF  theorems  stating  the  equivalences  for 
repetition  statements  given  in  Wirth  1971  are: 
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V«  S.  M$(mkcmpnd<mkwhila{o,$),E$))  * 

MS(mKcmpnd(mkcond(#,append(S,mKcmpnd(inkwhil#{t|S),ES)),ES)|ES))i 

V«  $  f  MS(mkcmpnd(mkrapeat(S,e),ES),M  *  v  rc\ rcr  rcrr  r\ 

M$(app«nd($1mk£mpnd(mkcond(-nkb«xprl(not,«),mkcmpnd(mkr«p*a1{S,«),E5),E5),E5)),t), 

Vi  *1  «2  S  f.  M${mkempnd(mkfor»o(i,«lle2,$),ES),f)  ■ 

MS(mkempnd(mktond{mkrol{lsoqle.l,o2)1  ......  „  „...  .. 

mkcmpnd(mkass(it«l  )|ipp#fid(S»wkcmpnd(mkforto(iPwktxprl  (plus  1  ti)|t2pS)|ES)))pES)pES)pf)i 

Vi  «1  e2  S  f  MS(mkcmpnd(mk<0rdn{i,el,e21S),ES),f)  * 

MS(mkcmpnd(mkcond(mkr#l(jreq,el  ,*2), 

mkempnd(mkass(i,«l  )1app«nd(Slmkcmpnd(mkfordn(i1mkexprl(minusl1i)l«2lS),ES))),ES),E5),t)1 

All  the  proofs  of  the  above  statements  are  one  step  proofs  In  fact.  we  have  defined  the  semantics  of 
the  repetition  statements  directly  in  terms  of  the  equivalence  described  in  Wirth  1971 


Section  4.5  Miscellaneous  theorems  on  MDtC,  MDEF,  MS 

Our  aim  in  this  section  is  not  to  give  an  exhaustive  list  of  the  properties  of  PASCAL,  but  rather  to 
show  some  typical  example  of  theorems  which  have  been  used  in  the  proofs  presented  in  this  report. 

Fir  t  of  all  we  want  to  state  that  type  definitions  and  declarations  are  independent  of  the  order.  The 
theorem  proved  for  type  definitions  is: 

isnamefnl  );;isnama(n2)ttnl jfn2"ISABSENT(nl ,s{f))t5l$A8$ENT(n2,i(0) 

MDEF(mkcmpnd(mklyp«def(nlIiyl)lmkcmpnd{mk1yp*deUn2,»y2),ES)),f,s)  » 
MDEF(mkcinpnd(mktyp«d«f(n2lty2)1mkcmpnd{mktypadef{nI,tyl  ),ES)),f,s); 

This  theorem  states  that  if  nl  and  n2  are  different  names  and  they  do  not  appear  in  the  store,  then 
the  order  of  type  definitions  using  these  names  as  type  identifiers  is  irrelevant.  The  predicates 
appearing  in  it  have  an  obvious  meaning:  i  is  the  negation  of  »,  ISABSENT  is  the  negation  of 
ISPRESENT  The  proof  of  this  theorem  has  not  been  included  in  the  report  since  it  is  a  very  simple 
proof  done  by  simplification  and  using  some  properties  of  conditional  expressions.  Analogously  the 
following  theorems  can  be  proved.  They  state  that  declarations  are  independent  of  the  order. 


Vnl  n2  tyl  Iy2  I  s  .  ,  „  .... 

isnamefnl  )::isnam«(n2)::n  I /n2  ::IS AB SENT (n  1  ,s(f ))::IS ABSENT (n2,s(f )).. 
MDEC(mkcmpnd(mkvardecl(nl  ,ty  1  ),mkcm|jnd{mkvardecl(n2,ty2)1ES)),f,s)  * 

MDEC(mkcmpnd{mkvard*cl(n2,ty2)1mkcm|md{mkvirdecl(nl,lyl  ),ES)),f,s); 


Vnl  n2  tyl  ty2  fs2  f  s  . 

isnamefnl  )::isnama{n2)::nl  /n2::l$AB$ENT{nl  ,s{f))::ISABSENT(n2,s(f)):t 

MDEC(mkcmpnd(mkvard«l{nl ,ty  1  ),mkcmpnd{mkfundecl(n21f»2,ty2),ES)),t,s)  • 
MOEC(mkcmpnd(mkfund«cl(n2,fs2,ty2),mkcmpnd(mkvardeel(nl,tyl),E$)),f,s); 


Vnl  n2  tyl  ty2  fsl  <s2  t  s  . 

i«nam«(nl  )s:isnam*(n2)s:nl  /n2s:ISABSENT(nl  ,s{f))::ISABSENT(n2,s(f)):r 
MDEC(mkempnd{mkfundecl(nl  ,f*l  ,ty  1  ),mkcmpnd<mkfundecl(n2,fs2,ty2),ES))ff,s)= 

MDEC(mkcmpnd(mkfund«el(n2,ts2,ty2),mkcmpnd(;Tikfundecl(nllfsl,tyl  ),E$)),f,s); 
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Vnl  n2  tyl  Isl  ps2  1  s 

isname(nl  )::isname(n2)::nl  /n2 ::IS A BSENT (n I  ,s(l))::l$AB$ENT(n2,s(f)):: 
MDEC(mkcmpnd(mK<undecl(nl  ,fsl  ,t>  1  ))mkcmpnd(mkprocdecl(n2,ps2)1ES)),f1s)  * 
MDEC(mkcmpnd(mkprocded(n2,ps2  ),mkcmpnd(mkfundod(nl  ,fs  1  ,ty  1  ),E$)),l,s); 

Vn  1  n2  ty  1  ps2  (  s  . 

isnamo(nl  )::isname(n2)::nl  /n2::ISA8SENT(nl  ,s(<))::ISABSENT(n2,s(f)):t 
MDEC(mkcmpnd(mkvarded(nl  ,ty  1  ),mkcmpnd(mkprocdecl{n21ps2),ES)),f.s) « 

MDEC(mkcmpnd(mkprocded(n2,ps2),mkcmnnd(mkvarded(nl  ,ty  1  ),ES)),f,s); 


Vnl  n2  psl  ps2  Is 

is  name  (nl  )::isname(n2)::nl  /n2  ::ISABSENT(nl , s(f  ))::IS  ABSENT  (n2,s(f )):: 
MDEC(mkcmpnd(mkprocded(nl  ,psl  )1mkcmpnd(mkprocded(n2,ps2),ES))l(ts)  E 

MDEC(mkcmpnd(mkprocdecl(n2,ps2),mkcmpnd(mkprocdocl(nl,psl  ),ES)),l,s); 


Some  theorems  describing  properties  of  MDEF  and  MDEC  are  now  listed.  Each  of  them  has  been 
proved  in  one  step. 


V  x  y  (  MDEF(mkcmpnd(x,y),<)‘MDEF(x,l)®MDEF{y,l); 


V  x  y  I  MDEF(mkvarded(x,y),f):  ID; 


V  x  y  z  1  MDEFImkfundedlx.y.z),!)3  ID; 


V  /  y  «.  MDEFfmkprocdecKx.yl.f)*  ID; 

V  x  y  1.  MDEF(mK‘,ypede«(x,y),f)3  CREAT(f,x,y); 

Vf.  MDEF(ES,f)=ID; 

V  x  y  1.  MDEC(mkcmpnd(x,y),f)sMDEC(x,f)®MDEC(y,''; 

V  x  y  1.  MDEC(mkvarded(x,y),03  CREAVff.x.y.Oi 

V  x  y  z  f  MDEC(mk<unded(x1y,z)1f)5  CREAF(f ,x,y ,z,f ,f ); 

Vxyl.  MDEC(mkprocded(x,y),03  CREAP«,x,y,f); 

VI  MDEC(ES,«)-ID; 

III  the  following  we  present  some  of  the  theorems  dealing  with  MS,  the  combmators  defining  the 
semantics  of  statements  and  some  predicates  used  by  the  semantic  combmators.  The  proofs  of  these 
theorems  are  very  simple  (one  step;,  however  they  were  useful  in  proving  programs  as  well  as 
properties  of  MS 

V<  MS(E$,<)’ID; 

Vx  y  f  MS(mkcmpnd(mkread  x,y),f)'REAO(x,<)®MS(y,<); 

Vx  y  f  MS (mkcmpnd(mkwrite  x,y),<)-WRITE(x,f)©MS(y,f); 

Vxl  x2  y  <.MS(mkcmpnd(mkass(xl,x2),y),<)=A$SIGN(xl,MEXPR(x2,0,0®MS(y,0; 
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Vn  f  s.ASSIGN(n,UU1f,s)-UU; 

Vn  e  LASS!GN(n,e,f,UU)2UU; 

Vn  <  WRITE(n,f,UU)JUU; 

Vn  f  READ(n,<,UU)^UU; 

MEXPR(UUTUU; 

BINDOJUHJU; 

MPB(UU)sUU; 

VI  f  FETCH(l,f,UU)=UU; 

Vn  f  PROCDEF(n,f,UU);UU; 

Vn  f.PROCFAL(n,f,UU)=UU; 
MD(UU)=UU; 

Vn  <  PROCTXT(n,f,UU)=UU; 

Vn  f  PROCDECL(n,f,UU)=UU; 
Vf.CLEAR(f,UU)=UU; 

Vloc  ISLOCAL(loc,UU)=UU; 
ISINBOUND(UU)=UU; 

Vty  ISADMISVAL(ty,UU)!UU; 
Vv  <  s  IS»NTYPE(v,UU.f,s)-UlJ; 
Vp  e  f  ISINTYPE(v,etfpUU)=UU; 
V(,ISPROCFRAME(f,UU)=UU; 
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SECTION  5  EXAMPLES 

In  this  section  we  want  to  discuss  how  to  prove  PASCAL  programs  in  LCE.  Two  examples  will  be 
fully  described 

1)  the  factorial  program, 

2)  the  McCarthy  Airline  reservation  system. 

We  have  also  proved  correct  a  PASCAL,  program  for  the  computation  of  the  GC.D  of  two  positive 
integers  with  the  euclidean  algorithm  and  a  PASCAL  program  for  the  computation  of  the  norm  of  a 
vector  These  proofs  have  been  executed  using  an  earlier  version  of  the  LCF  axiomatization  of 
PASCAL  and  are  described  in  Aiello  and  Aiello  1971.  We  have  not  rerun  them  on  the  final 
version  of  the  axioms  because,  even  though  many  detai's  have  been  changed,  the  underlying  ideas 
have  not  been  modified,  so  the  proofs  would  remain  very  similar. 


Section  5.1  The  factorial  program 

The  partial  correctness  of  a  program  for  the  computa  ion  of  the  factorial  function  has  been  alieady 
proved  in  LCF  and  discussed  in  Weyhrauch  and  Milner  1972.  The  proof  presented  here  is  very 
similar  to  that  one  We  have  included  it  because  the  factorial  program  is  a  very  simple  and  familiar 
example,  so  it  is  easy  to  go  through  the  proof  of  its  correctness  By  comparing  the  proof  given  here 
and  that  given  in  Weyhrauch  and  Milner  1972  it  may  be  seen  that  even  though  the  programming 
language  described  here  is  much  richer,  the  proof  isn’t  more  complex. 

A  PASCAL  program  which  computes  the  factorial  function  is  the  following. 

» 'nr  nl,n2 :  integer 
begin 
reaii(nl); 
read(n2 ); 
while  n2/B  do 

begin  nt,  =  nl  n2;n2.=n2-l,  end, 
write(nl); 

end; 

If  the  input  consists  of  two  nonnegative  integers  x  and  n  this  program  computes  x  nf.  The  factorial 
function  is  obtained  if  x  equals  I 

in  this  program  the  repetition  is  performed  by  a  while  statement,  hence  we  will  call  it  while-program 
An  analogous  program  for  the  computation  of  the  factorial  function  may  be  also  written  using  a 
goto  statement  (it  will  be  called  goto-piogram): 

rnr  nl,n2  integer 
begin 
read(  nl); 
read(n2), 
l  if  n2/B  then 
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hr /(ill  nl:=‘nifn2;n2:’‘n2-llfioto  I;  rnd; 
wrih(nl); 
rnd; 

In  LCF  both  programs  are  provable  correct  with  respect  to  the  function  FACT: 

FACT  *  [ocF  [Xn  x.n«0  -»  x,F(pr*d  n,n#x)]], 

FACT  applies  to  two  arguments  n  and  x  and  evaluates  to  x#nl. 

In  the  following,  the  LCF  proof  of  the  while-program  is  described  in  details.  This  program  has  no 
goto's,  so  the  theorems  described  in  4  2  for  goto-i'ree  programs  can  be  used,  making  the  proof  much 
simpler.  The  proof  of  the  sicond  form  of  factorial  program  will  only  be  sketched 

The  abstract  syntactic  form  of  the  while-program  is: 

FACTORIAL  »  mKt«xt(DP,SP), 

DP  *  mkcmpnd(mkvard«el(nl  .INTJ.mkcmpndfmkvardaclOtf.INT^ES)), 

SP  s  mkcmpnd(mkread{n2),mkcmpnd(mkread(nl ), 

mkcmpnd{mkwhil«{test,body),mkcmpnd{mkwrit«(nl  ),ES  ))>), 

fast  *  mkbexprl  (not.mkreKeq.na.mknumconsKB))), 

body  *  mkcmpnd(mkass(nl  )mkaxpr2(lim8s1nl1n2))1mkcmpnd(mkas*(n2,mk«xprl (minutl ,n2)),ES)) 


The  form  of  the  LCF  theorem  to  be  proved  is: 

Vn  x.isnat(n)::isnat(x)::APPLY{FACTORIAL,n,x)cFACT{n,x). 

Informally,  it  says  that  the  evaluation  of  the  program  FACTORIAL  on  the  data  n  and  x,'  if  it 
terminates,  gives  the  same  result  as  the  computation  of  the  function  FACT  on  n  and  x.  APPLY  is  the 
following  combinator- 

APPLY  s  [X  p  x  y  fstof (FUNCT(p,EOF,LIST (x,y)))}, 

LIST  s  [X  x  y  mkpair (x.mkpair (y.EOF ))]. 

As  said  in  section  2,  FUNCT  maps  sequences  of  integers  into  sequences  of  integers.  Given  a  program  p 
and  two  input  numbers  x  and  y,  APPLY  applies  the  combinator  FUNCT  to  the  sequence  LI$T(x,y)  and 
then  takes  the  first  element  of  the  output  sequence. 

The  method  used  to  prove  the  partial  correctness  of  the  while-program  is  quite  standard  'or  proving 
programs  with  a  while  loop  All  the  coinbinators  appearing  on  the  term  at  the  left  hand  side  are 
substituted  by  their  definition.  After  some  simplification  (automatically  done  by  LCF)  the  goal  to  be 
proved  is 
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Vn  x  isnat(n)  ::  isnai(x)  :: 

RESULT<WRl  I  E(ni  ,0,WHILE(MBEXPR(l«sltB),MS(body,0),READ(nl  ,0,READ(n2,0, 

CREAV(0,n2,INT,0,CREAV(0,nl  , INT  ,0,FRAME0(FACTORIAL, INPUT (LIST(n,x)), EOF))))))))  c  FACT(n,x) 

where  RESULT  is  defined  as  Vx.RESULT  x  =  IstoKOUTPUT  x).  The  theorem  on  the  while  statement 
given  in  section  4.3  for  goto  free  programs  has  been  used  in  achieving  the  above  goal.  The 
semantics  of  the  loop  is  expressed  in  terms  of  the  WHILE  combinator.  As  it  can  be  seen  from  the 
printout  in  appendix  7.2  the  proof  is  done  by  induction  on  the  WHILE  combinator  The  base  case  is 
trivially  proved  The  induction  step  is  proved  by  cases  on  the  predicate  which  controls  the  loop,  te 
-(n=0)  If  -(n=0)  is  false  then  the  result  easily  follows,  if  Mn=B)  is  undefined  a  contradiction  arises 
because  n  is  a  natural  number  If  '(n=B)  is  true,  the  goal  is  proved  by  a  proper  instantiation  of  the 
induction  hypothesis.  It  is  instantiated  for  pred  n  and  x*n.  Usually,  in  programs  for  the  computation 
of  the  factorial  of  ?.  natural  number  the  variable  nl  is  not  inputed  a  value,  but  it  is  initialized  to  I 
The  initialization  of  nl  to  x  results  in  a  strengthening  of  the  induction  hypothesis.  In  fact  the 
variable  x  appears  universally  quantified  in  the  statement  of  the  theorem  to  be  proved  and  can  be 
properly  instantiated  Actually  the  proved  theorem  is  stronger  than  'he  desired  one  The  factorial 
program  is  obtained  by  giving  the  value  I  to  x  in  the  above  theorem. 

The  proof  given  in  appendix  7  2  is  generated  by  the  list  of  commands  given  in  appendix  7.1  We 
want  again  to  point  out  that  LCF  is  not  an  automatic  theorem  prover.  It  has  only  a  subgoaling 
mechanism  and  a  sophisticated  simplification  algorithm  which  converts  terms  and  simplifies  them  by 
using  the  axioms  and  theorems  put  (by  the  user)  into  a  "simplification  set” 

In  the  simplification  set  there  are  all  the  syntactic  constructors  and  selectors,  plus  the  semantic 
combmators  appearing  in  the  first  line  of  the  list  of  commands.  Note  that  LCF  labels  are  prefixed 
by  a  each  axiom  has  been  labeled  with  an  identifier  equal  to  the  combinator  being  defined,  and 
INDUCT  is  the  label  of  the  induction  hypothesis.  The  modifications  done  to  the  simplification  set  after 
the  proof  is  started  (SS*/-somethmg)  are  done  only  to  increase  the  readability  of  the  goals.  In 
addition,  to  inciease  the  readability  of  the  proof,  a  combinator  FRAME  1  is  introduced  to  describe  an 
intermediate  store: 

FRAME  1  *  [XI  n  x.[Xl.f=0-* 

[Xloc loc=n2  -*n, 
locsnl  -*x, 

loc=1ypoloc  n2  -*  INT, 
loc=typeloc  nl  -*  INT, 
locsfileloc  INP— »  EOF, 
loc=fileloc  OUT-*  EOF, 
loc=1ex1loc  -*  l,UNDEF],UU]]. 

In  the  printout  of  the  proof  each  step  appears  with  its  "reason",  namely  the  tactic  used  in  achieving 
it.  as  well  as  the  step  numbers  of  the  axioms  and  the  names  of  the  theorems  involved  in  the 
simplifications  The  theorems  THI,  TH2...  are  general  theorems  about  the  semantics,  they  are  some  of 
the  theorems  listed  in  section  4.3  and  4.5.  Theorems  named  ARITH1,  ARITH2  deal  with  the 
arithmetic,  they  are  taken  from  Newey  1973.  Theorems  named  LMI,  LM2  are  specific  lemmas  about 
this  program  All  of  them  have  been  proved  in  the  same  environment  as  the  mam  theorem  and  their 
proofs  are  very  simple  Often  the  proof  reduces  to  a  one  step  simplification  They  are: 
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READ(nl  ,0,READ(n2)0,CREAV(0,n2,INT,0,CREAV(01nl  ,INT,0, 

FRAME0(FACTORIAL,INPUT(LI$T(n,x)),EOF)))))*FRAMEl  (SP,n,x) 

ASSUME  isnat  x  *  TT,  imat  n  *  TT 

which  implicitly  defines  the  frame  FRAME1, 

MS(body,0,FRAMEl(SPln,x))s  FRAME  1  (SP.pred  n,x*n)  ASSUME  isnat  x  *  TT,  -(n*0)aTT. 

It  specif  ies  the  effect  of  the  meaning  function  MS  on  the  body  of  the  while  statement.  Moreover 

MBEXPR(lest,0,FRAMEl  (SP,n,x))s  -(n=0)  ASSUME  isnat  n  *TT,  isnat  x*TT 

evaluates  the  test  appearing  in  the  while,  and  finally 

RESULT(WRITE(nl  ,0,FRAME1  (SP,n,x)))*FACT(n,x)  ASSUME  -tn«0)*FF,  isnat(x)*TT; 

asserts  that,  when  the  loop  is  over,  the  value  of  the  varibte  nt  is  FACT(n,x). 

As  already  noted  the  proof  is  fearly  standaid  and  could  be  almost  completely  automated  by 
increasing  the  proving  capabilities  of  LCF.  The  case  of  the  goto  program  the  proof  is  standard  as 
well,  but  much  longer.  In  fact  the  theorem  presented  in  4.3  no  longer  applies,  so  the  goal  u  be 
proved,  after  the  first  simplification  is: 

Vn  x  .  isnal(n)  ii  i’nat(x)  :: 

RESULT(MS(miv»mpnd(rr  labstatd  ,mkcond(test, 

mkempnd(mkass(nl  ,mkexpr2  (times.nl  ,n2)), 
mkcmpnd(mkass(n2,mkexpr  1  (minusl  ,n2)), 
mkcmpnd(mkgoto(l  l.ESHLESH.mkcmpndlmkwritelnt  ),ES)),0, 

READ(nl  ,0,READ(n2,01CREAV(0,n2,INT,0,CREAV(0,nl  ,INT,fj, 

FRAME0(FACTORIAL,MPUT{UST(n,x)),EOF)»m)  c  FACT(n,x) 

In  order  to  prove  it  bv  induction  on  MS  a  possibility  is  that  of  proving  the  above  goal  in  parallel 
with  the  following  3  goals: 

Vn  x  .  isnat(n)  isnat(x)  :: 

RESULT([\s.COND(MBEXPR(toSt,0,s), 

MS(mkcmpnd(mkass(nl,mkoxpr2(times,nl  ,n2)), 
mkcmpnd(mkass(n2,mkexpr  1  (minus  1  ,r.2», 
mkcmpnd(mkgoto(  1  ),mkempnd(mkwrit«(nl  ),ES)))),0,s), 

WRITE(nl  ,0,s)] 

READ(nl  ,0,READ(n2)0,CREAV(0,n2,INT,0,CREAV(0,nl  ,INT,0, 
FRAMEO(FACTORIAL,INPUT(LIST(n,x)),EOF)»»)  c  FACT(n.x). 

Vn  x  .  isnat(n)  ::  isnat(x)  :: 

RESULT([Xs.COND(MBEXPR(tost,0,s), 

ASSIGN(nl,MEXPR(mkexpr2(times,nl,n2),0),s)® 

MS(mkempnd(mkass(n2,mkexpr  l  (minus  1  ,n2)), 
mkempnd(mkgoto(l  ),mkempnd(mkwrite(nl  ),ES)))),0,s>, 

WRITE(nl  ,0,s>] 

READ(nl  ,0,READ(n2,0,CREAV(0,n2,INT,0,CREAV(0,nl,INTt0, 
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FRAME0(FACTORIAL,INPUT(LIST(n,x)),EOF))))))  c  FACT(n,x). 

Vn  x  isr  at(n)  ::  isnat(x)  :: 

RESULT ([As.CONDIMBEXPROest.O.s), 

ASSIGN(nl,MEXPR(mko/pr2(«imos1nl,n2)10)1s)» 

A$$IGN(n2,MEXPR(mkexprl  (minusl  ,n2)),0),s>® 

MS(  mkcmpnd(mk^oto(l  ),mkcmpnd(mkwrite(nl  ),ES)))),f),s), 

WRITE  (n  1 ,0  '.)] 

READ(n  1 ,0,READ(n2)0,CREAV(flln2,INT)fl)CREAV(fl,n  I  ,INT,B, 
FRAME0(FACTORIALpINPUTvLIST(n,x)),EOF))))))  c  FACT(n.x). 

In  this  way  there  are  four  induction  hypotheses  to  be  instantiated  and  it  can  be  seen  that  each  of 
them  serves  to  prove  the  next  goal  in  the  above  order.  Even  this  tricky  way  is  standard.  It  can  be 
applied  whenever  in  a  program  a  backward  goto  is  encountered.  In  addition,  such  tactic  could  also 
be  implemented  in  a  PASCAL  oriented  version  of  LCF,  so  the  user  is  relieved  from  the  task  of 
generating  all  the  parallel  goals. 


Section  5.2  The  McCarthy  Airline  Reservation  System 

John  McCarthy  suggested  the  problem  of  proving  the  correctness  of  a  program  for  the  reservation 
system  of  the  McCarthy  Airline  Company.  Such  company  has  one  plane,  with  only  one  seat.  The 
plane  never  flies'  There  are  iwo  customers,  each  one  sometimes  makes  a  reservation  and  then,  ti-ed 
of  waiting  for  the  departure  of  the  plane  he  cancels.  Later  on  he  may  try  again. 

Proving  the  correctness  o^  a  program  for  the  McCarthy  Airline  reservation  system  is  interesting 
since  it  presents  some  characteristics  absent  in  the  programs  so  far  proved  correct.  A  program  which 
realizes  a  reservation  system  must  deal  with  a  potentially  infinite  stream  of  input  data  "read"  at 
successive  instants  of  time.  Eacn  time  a  request  is  inputed,  an  output  datum  is  produced  The 
correctness  of  incremental  computations  cannot  be  dealt  with  in  a  system  where  the  input  and  output 
operations  aren’t  mentioned. 

Usually,  in  the  existing  systems  for  program  verification,  I/O  is  completely  ignored.  It  is  not 
considered  to  influence  the  "meaning”  of  a  program.  In  fact,  existing  systems  deal  with  algorithms, 
rather  than  programs,  even  though  such  algorithms  are  expressed  in  the  syntax  of  a  programming 
language. 

Our  axiomatization  of  PASCAL  includes  the  operations  of  inputing  data  from  an  input  file  into 
locations  of  the  store  and  outputmg  data  from  the  store  into  an  output  file  The  length  of  these  files 
isn’t  fixed  a  priori,  even  for  a  particular  program. 

In  our  formalism  we  may  express  and  prove  a  statement  of  the  correctness  of  a  PASCAL  program 
for  the  McCarthy  Airline  reservation  system.  Such  statement  asserts  that,  no  matter  what  the 
sequence  of  requests  has  been,  the  seat  at  any  inslant  of  time  is  reserved  for  the  right  person 

Let 

st  denote  the  seat, 
tul  denote  the  waiting  list, 
rq  denote  the  request  and 
ps  denote  the  passenger 
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The  variable  st  may  assume  the  values  8,  I  or  2  meaning  free,  reserved  for  passenger  1  or  2  The 
vaeiable  tol  assumes  the  values  0,  I  and  2  with  the  same  meaning,  rq  may  assume  the  value  0  and  I 
for  cancellation  and  reservation,  respectively,  ps  assumes  the  values  I  or  2,  denoting  the  two 
passengers. 

A  PASCAL  program  realizing  the  McCarthy  Airline  reservation  system  is  the  following' 
hegin 

var  st,u)l,p:,rq:  integer; 
read(iul); 
read(st), 
repent 
hr  gin 
read(rq); 
if  rq+3 
then  he gin 
read(ps); 
if  rq-1 

thei\  if  slmB  v  stmps 

then  St:mpS  elite  Ull:mpS; 
elte.  if  stmB  v  stJps 

then  u)l:*B  clue  he  gin  St  :*  till  end 
writ  e(  st) 
end 

until  rq-3 
end 

The  program  consists  of  an  initialization  part,  in  which  the  initial  status  of  the  seat  and  the  waiting 
list  (presumably  both  0)  are  inputed,  and  of  a  repeat  loop.  The  body  of  the  loop  consists  in  reading 
new  data,  updating  the  status  of  the  seat  and  the  waiting  list  and  then  writing  the  status  of  the  seat 
into  the  output  buffer.  An  extraneous  value  in  the  input  sequence,  in  this  case  the  number  3,  stops 
the  repetition. 

This  program  doesn't  make  any  assumption  on  the  behavior  of  the  passenger  or  about  the  kind  of 
requests  it  receives.  Each  request  is  accepted  and  the  program  behaves  correctly  even  if,  for  instance, 
two  cancellations  in  a  row  are  done  by  the  same  person. 

The  abstract  syntax  for  the  above  program  is: 

McCarthy  *  mktexHDP.SP), 

DP  «  mkcmpnd(mkvard«cl(wl,INT),mkcmpnd(mkvardeclUt,INT), 

mkcmpnd(mkvardecl(rq,INT),mkcmpnd(mkvardecl(ps,INT),E$)))), 

SP  *  mkcmpnd(mkread(wl),mkcmpnd(mkroad(si), 

mkcmpnd(mkr*p*ai(BODY,mkrel(eq,rq,mknumconst(3))),ES))), 

BODY  s  mkcmpnd(mkr#ad  rq,mkcmpnd(mkcond(mkrol(oq,rq,mknumconsi(3)),ES, 

mkcmpnd(mkread  ps,$EATUPDATE)),E$)), 


SEATUPDATE' 
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mkcmpnd(mkcond(mkrel(eq,rq,mknumconsl  1 ), 
mkcmpnd(nikcond(mkbexpr2(or,mkrol(cq,sl,mknumconsl  8),mkrol(eq|St,ps)), 
mkcnipnd(mka5s(r.t,ps)1CS),mkcmpnd(mkass(wllps)lES)),ES)1 
mkcmpnd(mkcond(mkbe:<pr2(orlmkrel(eq,st,mknumeonsi  B),mkbexprl  (not,mkrel(fcq,st,ps))), 
mkcmpnd(mkass(wl,mknumconsl  B,ES), 

mkcmpnd(mkass(',.tlwl)lmkcmpnd(mkass(wllmknumcon:  *  0,ES))),ES)), 
mkcmpnd(mkwrite  st,  ES ) ), 

The  statement  of  the  partial  correctness  of  the  McCARTHY  program  is: 

Visq  osq  p  q.iswfsq(isq)::iswfos(osq)::isinl(p)::ism1(q):: 

APPLYlMcCARTHY.p.q.isq.OsqJcBOOKINGIp.q.isq.Osq), 

where  isq  denotes  the  input  sequence,  osq  denotes  the  initialization  of  the  output  buffer,  namely  the 
output  sequence,  p  and  q  are  the  initial  values  of  the  waiting  list  and  the  seat. 

The  predicate  iswfsq  (is-well-formed-sequence)  is  defined  as. 

iswfsq  «  [ocF.[Xsq  («ll(sq)*  3HTT,iseof  sq  -*UU,isrqst(«ll  sq)Aisprsn(el2  sq)-»F (tail  1  sq),FF]J, 

where  ell,  el2,  tail  1 ,  isrqst  (isrequest)  and  isprsn  (isperson)  are  defined  as  follows: 

ell  *  [Xx.  fstof  x], 

el2  s  [Xx.  ell  (rmdof  x)], 

tail  1  *  [Xx.  rmdof(rmdof  x)], 

isrqst  *  [Xx  (x=0)v(x=  1 )], 
isprsn  s  [Xx.(x-1  )v(x=2)]. 

The  predicate  iswfos  (is-well-formed-output-sequence)  is 
iswfos  *  [o<F.[Xos  iseof  os  -*  TT,isint(fstof  os)-*F(rmdof  os),FF]], 
and  must  be  satisfied  by  the  object,  presumably  EOF,  that  initializes  the  output  buffer. 

The  combinator  APPLY  appearing  in  the  definition  of  the  goal  is: 

APPLY  *  [X  p  x  y  is  os  FUNCT(plos,LI$T(x,y,is))], 

LIST  *  [Xx  y  is.  mkpair (x,mkpatr(y ,is))], 


FUNCT.  the  combinator  which  "interprets"  a  program  p  in  the  frame  where  the  input  and  output 
buffers  have  been  initialized,  is  described  in  section  2. 

The  fact  that,  at  each  moment,  the  seat  is  reserved  for  the  right  person,  is  expressed  in  LCF  by  the 
function  BOOKING 
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BOOKING  *  t«cF.[X  st  wl  sq  os. 
iseol  sq  -*  UU, 

(•II  sq*3)  -■*  os, 

F(taill  sq,stupdt(sq,st,wt),wlupdt(sq,st,w»),mkp*ir (stupdt(sq,*t,w»),os))]], 

where  stupdt  (seatupdate)  and  wlupdt  (waiting-listupdate)  are  defined  as: 

stupdt*[Xsq  st  wl  (•)  1  sq*lH(st*0)v(st*el2  sq)-»el2  sq,s»,(st*0)v  '(s»*«l2  sq)  -*  st.wl], 

wlupdt  '[Xsq  st  wl  (el  1  sq*l  )-*(st*0)v(st*el2  sq)-*wl,«l2  sq,0]. 

We  express  the  fact  that,  at  each  instant  of  time  the  program  "answers"  in  the  right  way,  by  stating 
that  it  behave:  correctly  on  input  sequences  of  any  length.  Being  extensional  our  semantics  cannot 
express  the  concept  of  elapsation  of  time,  but,  by  talking  of  sequences  of  any  length  we  give  an 
adequate  extensional  representation  of  a  continuing  process. 

The  list  of  LCF  commands  and  the  printout  of  the  proof  of  the  partial  correctness  of  the  McCARTHY 
program  with  respect  to  the  BOOKING  function  is  given  in  appendix  8.  The  goal  to  be  proved,  after 
the  first  simplification  is: 

Visq  osq  p  q  .  iswfsq(isq)  ::  iswfos(osq)  ::  isint(p)  ::  isint(q)  :: 

OUTPUTHMEXPR(rq,0,MS(BODY,0,READ(5t  O.READfwi.O, FRAME Hp,q  sq,osq)))))*3)-» 

REPEAT (MS (BODY, 0),MBEXPR(mkb*xpr I  (not, mkrel(cq,rq,mknumcon*W3))),0),0, 

MS  (BODY, 0, RE  AD(st,0,READ(wl,O, FRAME  l(p,q,isq, osq))))), 
MS(BODY,O,READ(st,0,Ri:AD(wl,H1FRAMEKp,q,isq)osq)))))  e  BOOKINGS, q,isq, osq) 

In  achieving  this  goal  the  theorem  on  the  repeat  statement,  given  in  section  4  3  has  been  used.  The 
combmator  FRAME1  is  introduced  to  increase  the  readability  of  the  goal  It  describes  the  store  after 
the  declarations  are  done 

FRAME  1  *  [Xx  y  sq  os.  [XI.(h0H[Xloc. 
loc=typoloc  ps-*INT, 
iocstypeloc  rq-*INT, 
loc=typeloc  »J-*INT, 
loc»typ«loc  w'-*INT, 

loc=fileloc  INP-*INTERNALREP(UST(x,y,sq)), 
loc=fileloc  OUT-MNTERNALREP  os, 
loc*t«xtloc  -»$P,UNDEF],UU]. 

The  proof  of  the  McCARTHY  program  differs  from  that  of  the  factorial  program  mainly  for  two 
reasons.  I)  the  while  and  the  repeat  statements  behave  differently,  having  the  test  performed  at 
different  places  2)  here  an  initialization  is  done  within  the  body  of  the  repetition  statement,  h  fact, 
the  two  values  of  rq  and  ps  art  read  within  the  loop.  For  this  reason  the  loop  must  be  executed  once 
in  order  to  create  a  location  named  rq  and  one  named  ps,  before  doing  an  induction  on  the 
combinator  REPEAT.  The  goal  is  proved  by  cases  on  the  test  which  controls  the  repeat  loop  The 
only  nontrivial  case  is  that  in  which  the  input  sequence  is  not  yet  over,  namely  rq/3  In  this  case  the 
repeat  loop  goes  or.,  so  an  induction  is  needed  for  completing  the  proof.  The  base  case  of  this 
induction  is  trivial  The  induction  step  is  proved  by  doing  again  cases  on  the  test  which  establishes 
the  exit  conditions  from  the  loop.  If  the  loop  is  completed  a  lemma  is  used  to  state  the  result,  if  it 
goes  on  the  goal  is  proved  by  an  appropriate  instantiate  of  the  induction  hypothesis 
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As  in  the  proof  of  the  factorial  program  the  theorems  used  in  the  proof  have  been  divided  into  THs, 
ARlTHs  and  LMs  THs  state  facts  about  the  semantics,  one  of  tl  <*m  is  the  above  mentioned  theorem 
about  the  seman  ics  of  the  repeat  statement  for  goto-free  programs.  They  are  shown  in  4  ?.  and  4  5. 
ARlTHs  are  theorems  dealing  with  the  arithmetic  and  properties  derived  from  the  above  axioms  on 
the  well  fori  ledness  of  input  and  output  sequences  LMs  are  specific  lemmas  regarding  this  program 
The  list  of  these  lemmas  follows 

Vsq  os  xl  x2.  MD(DP,0,FRAME0(McCARTHY,INPUT (LIST (x I ,x2,sq)),INTFRNALREP(os)))s 

FRAMEI  (xl  ,x2,sq,os); 

is  an  implicit  definition  of  FRAMEI  It  defines  the  store  after  the  declarations  are  done 

READ(st, 0,READ(wl,0, FRAMEI  (xl,x2,sq,os)))'FRAME2(xl,x2,sq, os) 

ASSUME  iswfsq(sq)=TT,  iswfos(os)sTT,  isint(xl  )*TT ,  isint(x2)«TT 

This  statement  is  an  implicit  defim.ion  of  FRAME.  It  describes  the  store  after  wl  and  st  are 
initialized. 

FRAME2  *  [Xxl  x2  sq  os.  [\f  (f«0)-*[\loc. 
loc«st  -+x2, 

loc*wl  —*x  1 , 

loe*typeloc  ps-*INT, 
locMypoloc  rq— *INT, 
loc*typeloc  st— *INT, 
loc-typcloc  wl-*INT, 
loc-fiioloc  INP— *INTERN ALREP(sq), 
locslileloc  OUT-HNTERNALREP(os), 
loc=toxtloc  — *SPlUNDEF]fUU], 

The  next  theorem: 

OUTPUT  (MS(BODY,0,FRAME2(xl,x2,sq,os))hBOOKING<xi,x2,sq,  os) 

ASSUME  -(•II  sq  »  3  )*FF,isw»sq  sq*TT,iswfos  os5TT,isint  xl*TT,isint  x2»TT 

states  that,  when  the  input  sequence  is  ov.*r,  the  content  of  the  output  file  after  »he  execution  of 
BODY  in  the  store  described  by  FRAME2,  equals  the  value  of  the  function  BOOKING. 

BOOKING(stupdt  (sq,x,y  ),wlupdt(sq,x,y  ),t*il  1  sq.mKpairfstupdKsq.x.yJ.os^xBOOKINGlx.y.sq.Os) 

ASSUME  iswfsq  sq  *TT,iswfos  os  *  TT.isint  x  *  TT,  isinl  y  »  TT,'(*U  sq«3)*TT 
states  a  simple  property  of  the  function  BOOKING. 

MS(BODY)0,FRAME2(stupdt(sq,x,y),wlupdt(sq,x1y),taill  sq,mkpair(stupdt(sq,x,y),os)))* 
MSfBODY.B.FRAMESfx.y.sq.os)) 

ASSUME  iswfsq  sq  *TT,iswfos  os  •  TT.isint  x  *  TT,  isint  y  *  TT,'(ell  sq*3)«  TT; 

MS(BOOY,0,FRAME2(xIy,sq,os))-  FRAME3(x,y,sq,os) 
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ASSUME  iswfsq  sq  sTT.iswfos  os  *  TT,ismt  x  *  TT,  isint  /  »  TT ,-(el  1  sq*3)'  TT; 

The  two  above  theorems  use  the  combmator  FRAME3  to  describe  an  intermediate  store. 

FRAME3  «  [Xxl  x2  sq  os.  [Xf.(f*0)-*[Xloc. 
loc=ps  -*el2  sq, 

loc*rq  —»«l  1  sq, 

loc«st  -»stupdt(sq,xl,x2), 

locswl  — *wlupdt(sq,x  1  ,x2), 

loc*typeloc  ps— *INT. 
loc*typeloc  rq-»INT, 
loc=typoloc  st— *1NT, 
loc=typeloc  wMNT, 
loc-liieloc  INP-*taill  (INTERNALREP  sq), 

loc*fileloc  OUT-»mkpair(mknumconst  stupdt(sq,xl  ,x2),INTERNALREP  os), 
loc«t«xtloc  -*SP,UNDEF],UUJ; 


FRAME3  is  the  description  of  the  store  after  the  Lody  of  the  loop  has  been  executed  once. 
MEXPR(rq,0,MS(BODY,0,FRAME3(x,y,sq,os)))s  «I3  sq 

ASSUME  iswfsq  sq  sTT.iswfos  os  i  TT, isint  x  s  TT, isint  y  *  TT,-(ell  sq=3)  *  TT 

MBEXPRfmkbexprl  (not,mkrel(eq,rq,mknumconst(3))),0,MS(BODY,0,FRAME3(x,y,sq,os)))=  -(el3  sq  e  3) 

ASSUME  iswfsq  sq  *TT,iswfos  os  *  TT, isint  x  «  TT, isint  y  *  TT,-(el!  sq=3)«  TT 
MEXPR(rq,0,MS(BODY,0,FRAME2(x,y,sq,os)»*«ll  sq 
ASSUME  iswfsq  sq=TT,iswfos  os  ^TT, isint  x^TT, isint  y*TT. 

The  three  above  lemmas  are  introduced  to  abbreviate  the  evaluation  of  expressions. 
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SECTION  6  CONCLUSION 

Thp  most  important  aspect  of  this  memo  relates  to  our  attempt  to  axiomatize  all  of  the  arithmetic 
.  of  PASCAL  This  is  interesting  for  two  reasons.  rirst  we  are  able  to  describe  in  LCF  different 
Lemming  language  features  and  show  how  they  interact.  Secondly  we  can  express  property  of 
classes  of  programs  and  use  them  as  lemmas  in  proofs  of  theorems  about  particular  programs  A 
typical  example  is  the  theorem  about  goto-free  programs  in  section  4.2.  It  is  used  in  section  b  2  to 
simplify  the  first  proof  of  the  correctness  of  the  factorial  program.  When  interpreted  literally,  it 
' '  les  that  for  goto-free  programs  the  composition  rule  in  Hoare  I960  is  valid.  By  formulating  the 
validity  of  this  rule  as  a  theorem  we  can  discuss,  in  LCF,  the  relative  merits  of  various  programming 
features  This  has  not  previously  been  accessible  to  a  formal  treatment,  and  is  important  if  the 
mathematical  theory  of  computation  is  ever  to  have  an  effect  on  language  design. 

Our  desire  to  axiomatize  all  aspects  of  a  programming  language  is  not  simply  a  matter  of  choice  of 
availabV  formalisms  but  represents  a  philosophy  about  what  kinds  of  questions  the  mathematical 
theory  of  computation  should  ask  The  method  of  attaching  inductive  assertions  to  programs  treats 
Droe ranis  one  at  a  time.  We  do  not  think  general  theories  about  programs  can  oe  developed  in  this 
way  Of  course  using  inductive  assertions  is  not  a  waste  of  time,  but  formalisms  which  use  them 
should  be  expanded  to  include  moie  general  applicability. 

The  kind  of  questions  about  programs  we  have  in  mind  include  will  it  run  at  all,  even  if  its 
algorithm  is  correct5  Will  it  compile?  Does  some  other  coding  or  "optimization  compute  the  same 
function5  We  believe  that  LCF  is  capable  of  expressing  these  notions.  Furthermore,  any  formalism 
for  describing  a  programming  language  could  reasonably  be  expected  to  have  this  property 

We  criticize  the  original  description  of  PASCAL,  not  because  W.rth  didn’t  have  philosophically 
reasonable  ideas  of  what  various  features  of  a  programming  language  should  do,  but  rather  he 
laced  a  formalism  which  was  strong  enough  to  describe  the  effect  of  putting  together  features, 
which  although  separately  mrke  clear  sense,  cause  problems  when  combined  The  example  of  the 
procedure  in  the  discussion  of  the  for  statement  is  a  case  in  point.  It  is  net  a  PASCAL  procedure  as 
he  value  of  the  index  variable  of  the  for  statement  is  changed  in  its  body.  This  fact,  however  is 
hard  to  detect  and  is  certain  to  be  missed  by  most  compilers.  The  difficulty  arises  out  of  the  desue 
not  to  make  the  index  of  a  for  statement  local  to  that  statement,  to  have  the  limits  of  the  for  loop 
variable  detei mined  once  and  for  all  and  to  have  recursive  procedures  in  the  same  language 
Features  when  combined  in  arbitrary  ways  make  even  the  recognition  of  well  formed  programs 
complicated  Further  evidence  of  this  difficulty  is  found  in  the  large  number  of  restrictions 
Iearashi  London  and  Luckham  197?  have  put  on  the  application  of  their  rules  The  onl-  example 
of  a  procedure  given  in  Hoare  and  Wirth  1973  canrut  oe  treated  in  their  system  It  does  not  seem 
obvious  to  us  how  to  extend  'heir  style  of  axiomatizatiou  to  all  of  PASCAL.  We  do  not  impose  any 
of  their  restrictions,  but  describe  the  full  generality  allowed  by  W.rth.  The  expressive  power  of  LCF 
permits  us  to  represent  their  restrictions  and  to  prove  that  rules  similar  to  theirs  are  valid  for  the 

subset  of  PASCAL  they  treat 


The  above  should  reflect  on  language  design.  One  overwhelming  feeling  of  all  three  authors  alter 
domi  this  work  was  that  we  know  large  amounts  mote  about  how  to  describe  a  language  to  make 
proving  theorems  about  it  reasonable  We  believe  that  the  ability  to  describe  programming  features 
and  demonstrate  by  proving  theorems  that  a  language  has  certain  properties  represents  a 
particularly  satisfying  way  to  describe  a  language  Furthermoie  we  propose  this  as  a  standard  for 

acceptable  descriptions 
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One  possible  idea  for  future  work  is  designing  a  programming  language  using  the  more  precise 
description  of  this  paper.  Only  small  modifications  to  PASCAL  are  necessary  to  give  a  similar 
language  a  demonstrably  smoother  semantics  Thus,  by  starting  w-rh  a  more  detailed  description, 
some  properties  of  the  language,  which  could  only  be  informall"  described  before  would  now  be 
made  explicit  as  statements  in  LCF  One  could  then  begin  to  amass  a  collection  of  theoiems  that 
could  be  used  to  prove  properties  of  particular  programs.  We  could  then  integrate  everything  into 
an  LCF-PASC.AL  "machine”  which  took  a  concrete  PASCAL  syntax  and  generated  the  LCF 
abstract  syntactic  representation.  Of  course  the  new  language  would  have  to  include  more  features 
than  those  discussed  here.  Obvious  candidates  are  real  arithmetic,  file  manipulation  and  more 
complicated  data  structures  If  we  wanted  to  abandon  the  ALGOL  like  control  structures  it  would 
be  possible  to  choose  either  that  of  LISP  or  even  the  more  aggressive  control  structures  of  Bobrow 
and  Wegbreit  or  the  Landin  J  operator  It  would  be  an  interesting  project  to  describe  them  all  and 
see  what  theorems  hold  when  you  allow  them  to  exist  simultaneously. 

We  chose  to  work  out  the  McCarthy  airline  reservation  system  as  an  example  because  we  believe 
the  treatment  of  interactive  programs  is  another  area  which  a  vital  mathematical  theory  of 
computation  must  consider  Our  idea  for  how  »o  treat  the  correctness  of  continously  interactive 
programs  was  to  consider  them  as  functions  from  sequences  of  inputs  to  sequences  of  outputs  If  the 
processes  you  are  considering  are  commons,  that  is,  some  initial  sequence  of  outputs  is  completely 
determined  after  some  fixed  number  of  inputs,  then  equivalently  we  can  consider  the  correctness  of 
finite  output  sequences  given  finite  input  sequences.  Basically  this  idea  has  been  used  in 
intuitiomstic  theories  of  free  choice  sequence  as  developed  by  Brouwer  and  Klecne  (see  Kleene  and 
Vesley  1965). 

We  end  this  memo  with  some  comments  about  LCF.  A  major  difficulty  involved  in  using  LCF  as 
the  language  for  interpreting  programming  languages  is  that  descriptions  of  the  data  being 
manipulated  (in  our  case  integers)  is  awkwaio.  The  axiomatization  of  arithmetic  in  LCF  although 
adequate  is  both  non  standard  and  frequently  hard  to  us?  It  is  partially  the  fault  of  LCF  as  it  does 
not  implement  such  nice  user  oriented  features  as  arbitrary  structural  inductions.  It  forces  you  to  use 
computation  induction  in  its  primitive  form  Unfortunately  the  implementation  cannot  be  blamed 
for  everything  A  proof  of  Wilson's  theorem,  for  example,  would  be  virtually  impossible  even  by 
mathematical  induction.  LCF  terms  not  only  have  rnteipretations  as  functions,  but  can  also  be 
interpreted  as  computation  rules  Although  this  duality  has  not  been  fully  exploited  it  is  the 
essential  reason  that  the  simplification  mechanism  of  LCF  is  so  successful. 
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APPENDIX  I 

A  BRIEF  DESCRIPTION  OF  LCF 


The  syntax  of  LCF  sentences  is  described  in  detail  in  Milner  1972a.  Here  we  only  give  an  informal 
description  of  the  language,  its  interpretation  and  enough  of  the  abbreviation  conventions  to  make 
the  formulas  in  this  repoit  intelligible  to  those  not  familiar  with  LCF 

There  are  two  kinds  of  b  se  variables  and  constants  in  LCF.  Those  that  range  over  individuals 

and  those  that  range  over  truth  values.  Each  term  has  an  associated  type.  If  t  is  a  term  and  <r  its 

associated  type  symbol  wr  write  t <r  IND  and  TV  are  type  symbols.  If  a  and  r  are  type  symbols 

then  so  is  (<r-r).  We  wr.;e  x.IND  and  x:TV  for  x  of  type  individual  and  truth  values  respectively 
There  are  variables  and  constants  for  each  different  type  symbol.  The  variable  symbols  of  different 
types  are  supposed  to  be  disjoint  There  are  three  constants  of  type  TV.  They  are  TT  for  true.  FF 
for  false,  and  UU  for  undefined 

Terms  are  formed  as  follows:  if  x<r  is  a  variable  and  t.f  then  [Xx.t]:(<r-*r)  is  a  term  whose 
interpretation  is  a  function  from  things  of  type  <r  onto  things  of  type  T.  In  LCF  [Xx.[Xy  t]]  is 
abbreviated  by  [Xx  y.t]  If  r:(<r-.r ;  and  s  ff  then  r(s)  r  We  interpret  r(s)  as  the  result  of  applying  the 
function  r  to  the  argument  s  We  frequently  write  this  r  s.  thus 

ab(E  a(b)(cHa(b))(c)'a(b,c) 

Note  that  if  r  is  TV  then  r  is  a  predicate.  Conditional  expressions  are  formed  as  (p-*q,r),  where 
p:T V  and  q.  r  are  of  the  same  type  On  the  undefined  truth  value  the  conditional  is  undefined,  i.e. 
for  all  q  and  r,  (UU->q,r):UU.  Terms  ate  also  built  tip  using  the  least  fixed  point  operator  ec.  If  x  <r 
is  a  variable  and  s  traff  then  [*x.s]  is  a  term  representing  the  least  fixed  point  of  the  functional  s 

Atomic  well  formed  formulas  (or  AWFFs)  are  formed  by  joining  two  terms  using  *  or  e,  i.e.  if  r  and 
s  are  terms  then  r*s  and  res  are  AWFFs.  r*s  means  that  the  functions  denoted  by  r  and  s  are  the 
same  In  a  full  description  of  the  theory  there  is  also  a  partial  order  between  terms  of  the  same  type 
This  is  represented  using  e. 

The  more  usual  definition  of  the  factoiial  function  fact(n)  -  if  \-=0  t hen  I  else  n  fact(n-l)  becomes 
in  LCF 

FACT  =  [ocf  [X n. (n=0  — > I  ,n*f(n*l )]] 

LCF  also  allows  two  other  abbreviations. 

Vx.fsg  is  the  same  as  [Xx  f]=[Xx  g] 

Because  terms  are  interpreted  as  extensionally  given  functions,  this  definition  makes  sense. 

P::Q*R  is  the  same  as  (P— >Q,UU)s(P-»R,UU) 

Intuitively  this  is  read  as:  If  P  is  true  then  Q=R,  otherwise  I  don’t  know  anything 
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APPENDIX  2 

THE  ABSTRACT  SYNTAX 


2.1  Syntax  for  Statements 

AXIOM  SYNAXS: 

V  d  s.  typ«(mktext  d  s)  *  _T, 

V  d  s.  d*clot(mktext  d  s)  *  d, 

V  d  s.  statmot(mkt«xt  d  *)  *  *, 

V  dl  d2.  typalmkcmpnd  dl  d2)  *  .CM, 

V  dl  d2.  <stof(mkcmpnd  dl  d2)  *  dl, 

V  dl  d2.  rmdo*(mkcmpnd  dl  d2)  *  d2, 

V  n  ty.  typelmktypedef  n  ty)  *  _TD, 

V  n  ty  namo*(mktypcdot  n  ty)  £  n, 

V  n  ty  typotlmktypedef  n  ty)  *  ty, 

V  nl  n2.  typelmksublim  nl  n2)  £  _SL, 

V  nl  n2.  lbot(mksublim  nl  n2)  *  nl, 

V  nl  n2.  ubof(mksublim  nl  n2)  £  n2, 

V  ai  ty.  type(mkarspec  al  ty)  £  .AS, 

V  al  ty.  arlimo»(mkarsp«  al  ty)  £  al, 

V  al  ty.  typ«lot(mkarsp«c  al  ty)  *  ty, 

V  il  i2.  typ«(mkpair  il  i2)s  _PA, 

V  it  i2.  tsto*(mkpair  il  i2)»  il, 

V  il  i2.  rmdotlmkpair  il  i2)s  i2, 

V  n  ty.  typo(mkvardod  n  ty)  *  _V0, 

V  n  ty  namo<(mkvard*«l  n  ty)  *  n, 

V  n  ty.  typof(mkvard«cl  n  ty)  *  ty, 

V  n  ps.  typ«(mkprocdecl  n  ps)  *  _PD, 

V  n  ps.  namot(mkprocdecl  n  ps)  £  n, 

V  n  ps.  prspoflmkprocdecl  n  ps)  =  ps, 

V  n  ts  ty.  typo(nikfundocl  n  <s  ty)  £  _FD, 

V  n  <s  ty.  namotlmkfundocl  n  ts  ty)  £  n, 

V  n  ts  ty  tnspot(mktundecl  n  ts  ty)  £  Is, 

V  n  ts  ty.  typeof(mktundecl  n  ts  ty)  £  ty, 

V  t  ttypolmkprocspoc  <  t)  £  _PS, 

V  t  t  targotlmkprocspec  <  t)  5  t, 

V  t  t  textoHmkprocspec  t  t)  *  t, 

V  «  t.type(mk«unspec  t  t)  £  _FS, 

V  t  t  <argot(mktunspec  <  t)  *  t, 

V  t  t.textottmktunspoc  t  t)  *  t, 
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V  x  ty  type(mkvarp  x  ty)  e  _VRP, 

V  x  ty.  namoftmkvarp  x  ty)  e  x, 

V  x  ty  typoKmkvarp  x  ty)  *  ty, 

V  x  ty.  type(mkvalp  x  ty)  e  _VLP, 

V  x  ty.  namof(mkvalp  x  ty)  *  x, 

V  x  ty  'ypotlmkvalp  x  ty)  *  ty, 

V  x  ty.  type(mk<unp  x  ty)  e  _FP, 

V  x  ty  namof(mkfunp  x  ty)  e  x, 

V  x  ty  typof(mkfunp  x  ty)  »  ty, 

V  x  type(mkprocp  x)  *  _PP, 

V  x  namoKmkprocp  x)  *  x, 


V  I  s  type(mklabstat  i  s)  -  _LS, 

V  I  s  iabeloHmklabstat  I  5)  =  i, 

V  I  s  statmoKmklabstat  I  s)  1  s, 

V  n  typetmkread  n)  s  _RD, 

V  n.  namot(mkread  n)  e  n, 

V  n.  type(mkwrite  n)  *  _WT, 

V  n.  namo‘(mkwrite  n)  *  n, 

Vn.  type(mkgoto  n)  *  _G, 

Vn.  laboloHmkgoto  n)  e  n, 

Vn  e  type(mkass  n  e)  e  _A, 

Vn  e  Ihsoftmkass  n  e)  s  n  , 

Vn  e  rhsof(mkass  n  e) *  e  , 

V  n  a.  type(mkproccall  na)f  _PC, 

V  n  a.  namof(mkproccall  n  a  )  *  n, 

V  n  a.  actargof(mkproccall  n  a)  >  a, 

Vbe  pt  p2  typetmkcond  be  pi  p2)  «  _C, 
Vho  pt  p2.  testof(mkcond  be  pt  p2)  -  be, 
;>l  p2  thenof(rr.kcond  be  pt  p2)  *  pt, 
pi  p2  olsoof (mkcond  e  pi  p2)  e  p2, 

Vt  b  type(mkwhile  t  b)  e  _W, 

Vt  b  testoftmkwhile  t  b)  e  t  , 

Vt  b.  bodyof(mkwhile  t  b)  e  b, 

Vb  t  typo(mkrepoat  b  t)  s  _R, 

Vb  t.  bodyof(mkrepeat  b  t)  *  b, 

Vb  t  testoKmkropoat  b  t)  e  t  , 

Vi  ol  o2  b  typo(mktorto  1  et  e2  b)3_FT, 
Vi  et  o2  b.  md‘5xof(mktorto  i  el  e2  b)3  i, 
Vi  el  e2  b  lbot(mktorto  i  et  e2  b)r  el, 

Vi  el  o2  b  ubof(mk(orto  i  et  e2  b)E  e2, 

Vi  ol  e2  b  bodyottmktorto  i  el  e2  b)E  b, 
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Vi  el  e2  b  lype(mkfordn  i  el  e2  b)3_FD, 
Vi  el  e2  b  indcixo((mkfordn  i  el  a2  b)3  i, 
Vi  el  e2  b  uboKmklordn  i  el  e2  b)3  el, 
Vi  el  e2  b.  !bol(mKfordn  i  el  e2  b)=  e2, 
Vi  el  e2  b  bodyof(mK<ordn  i  el  e2  b)3  b, 


typo  UU  *  UU, 
type  ES  3  _E3, 
type  EOF  * .EOF; 


2.2  Syntax  for  Expressions 
AXIOM  EXPRAX: 

Vo  el.  type(mktxprl  o  el)  *  _E, 

Vo  ol  opo((mkoxprl  o  ol)  3  o, 

Vo  el.  arglof(mkexprl  0  el)  3  el, 

Vbo  bel.  type(mkboxprl  bo  bol)  3  _BF, 

Vbo  bel  bopof(mkbexprl  bo  bel)  3  bo, 

Vbo  bel  barglof(mkbexprl  bo  bel)  3  bel, 

Vo  el  e2.  type(mkexpr2  0  el  e2)  3  _E, 

Vo  el  e2.  opol(mkexpr2  0  el  c2)  3  0, 

Vo  el  e2  arglof(mkexpr2  0  el  e2)  3  el, 

Vo  el  e2.  arg2of(mkexpr2  0  el  e2) 3  e2, 

Vbo  bel  be2.  Iype(mkbexpr2  bo  bel  be2)  3  .BE, 
Vbo  bel  bo2  bopof(mkboxpr2  be2)  3  bo, 

Vbo  bel  bel.  barglo‘(mkbexf  1  r'e2)  3  bel, 

Vbo  bel  be2.  barg2of(mkbexpr  .  jol  be2)  3  be2, 

Vbo  el  e2.  type(mkre!  bo  el  e2)  3  .BE, 

Vbo  el  e2.  bopol(mkrel  bo  el  e2)  3  bo, 

Vbo  el  e2  arglof(mkrel  bo  el  e2)  3  el, 

Vbo  el  e2  arg2of(mkrei  bo  el  e2)  °  e2, 

V  n  i.  Iype(mkae  n  i)  3  _AE, 

V  n  i.  namol(mkae  n  1)  3  n, 

V  n  1  subof(mkao  n  i)  3  i, 

V  n  a.  lype(mkfundos  n  a)  3  _FA, 

V  n  a.  namoKmkfundes  n  a)  3  n, 

V  n  a.  adargol(mkfundes  n  a)  3  a, 


V  n  lype(mknumconsl  n)  3  _NC, 

V  n  numoltmknurriconsl  n)  3  n; 
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2.3  Predicates  for  the  Identification  of  Syntactic  Constructs 

AXIOM  PREDAX: 

Vx.  istext  x  £  typo  x  =  _T, 

Vx.  iscmpnd  x  *  typo  x  e  _CM, 

Vx  istypodof  x  £  typo  x  *  .TO, 

Vx.  issublim  x  £  typo  x  *  _$L, 

Vx  isarspoc  x  *  typo  x  ■  .AS, 

Vx.  ispair  x  *  typo  x  *  .PA, 

Vx.  isvardod  x  *  typo  x  *  _VD, 

Vx.  isproedod  x  *  typo  x  ■  _PD, 

Vx.  isfundod  x  £  typo  x  =  _FD, 

Vx.  isprocspoc  x  *  typo  x  =  .PS, 

Vx.  isfunspoc  x  £  typo  x  -  _FS, 

Vx.  isvarp  x  £  typo  x  *  _VRP, 

Vx.  isvalp  x  £  typo  x  *  .VLP 
Vx.  isfunp  x  £  typo  x  *  _FP, 

Vx.  isprocp  x  £  typo  x  *  _PP, 

Vx.  islabstat  x  £  typo  x  *  _LS, 

Vx.  isread  x  £  typo  x  s  _RD, 

Vx.  iswrito  x  £  typo  x  *  _WT, 

Vx.  isgoto  x  £  typo  x  *  _G, 

Vx.  isasi  x  £  typo  x  -•  _A, 

Vx.  isproccall  x  £  typo  x  *  .PC, 

Vx.  iscond  x  £  type  x  *  _C, 

Vx.  iswhile  x  £  typo  x  *  _W, 

Vx.  isropeat  x  £  typo  x  *  _R, 

Vx.  isforto  x  £  typo  x  «  .FT, 

Vx.  isfordn  x  £  typo  x  «  _FD, 

Vx.  isomptyst  x  £  typo  x  *  _ES  , 

Vx.  isoof  x  £  typo  x  *  .EOF, 

Vx.  isconst  x  £  typo  x  =  _NC, 

Vx.  isname  x  £  typo  x  *  _N, 

Vx.  isoxpr  x  £  typo  x  *  _E, 

Vx.  isboxpr  x  £  typo  x  *  .BE, 

Vx.  isrol  x  *  typo  x  «  _8E, 

Vx.  isao  x  =  typo  x  =  _AE, 

Vx.  isfundes  x  £  typo  x  *  .FA; 
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2.4  Auxiliary  Predicates  and  Functions 

AXIOM  AUXSYN  : 

isname  FUNV  *  FF, 

fstof  EOF  «  UU, 

rmdof  EOF  *  UU; 

issingle  s  [Xst  (isread  st Miswrite  stMissimple  st)v(isemptyst  st)], 
issimple  a  [Xst.  (isgoto  st)v(isass  st)v(isproccall  st)], 

fortest  £  [Xx  .isforto(x)-»mkret(lseq,lbof(x),ubot(x)),isfordn(x)-*mkrel(£req,ubof(x),lbof{x)),UU]  , 

fortoup  '  [Xx  mkcmpnd(mkforto(indexof(fstof{x)),mkexprl (plusl .indexof (fstof (x))), 
ubof(fstof(x)),bodyof  (fstof  (x))),rmdof(x))], 

fordnup  *  [Xx  mkcmpnd(mkfordn(indexof(fstof(x)),mkexprl  (minus  1  ,indexof (fstof (x))), 

Ibof  (fstof  (x)),bodyof  (fstof  (x))),rmdof(x))], 

isrepwh  a  [Xst.  (isrepeat  st)v(iswhile  st)], 

isiter  a  [Xst.  (isforto  st)v(isfordn  st)v(isrepwh  st)], 

isparameter  a  [Xx.  (isvarp  x)v(isvalp  x)v(isprocp  x)v(isfunp  x)], 

isbasetype  a  [Xn  (n=INT) v{type(n)=_SL)], 

istyppart  *  [Xn.ispair(n)viseof(n)], 

occurs  *  [ocF.[Xn  st. 

isemptyst  s*  UU, 
iscmpnd  st  -*  r(r>,fr<of  st)vF(n,rmdo*  st), 
islabstat  st  -»  (nslabciof  st)-»TT,F(n, rmdof  st), 
issingle  st  -»  FF, 

!s:ter  st  -»  F(n,bodyof  st), 

iscond  st  -»  F(n,thonof  st)vF(n,elsoof  st),UU]], 

append  *  [ocF.[X  stl  st2 

isemptyst  stl  -*  st2, 

iscmpnd  stl  -»  mkempnd(fstof  stl,  F(rmdof  stl,st2)),UU]], 

segm  a  [«>cF.[Xn  st. 

isemptyst  si  -»  UU, 
iscmpnd  st-* 

isemptyst  s;  -*F(r., rmdof  st), 

islabstat(fstof  st)— »{n=labolof  st)-*  st,F(n,mkcmpnd(statmof(fstof  st), rmdof  st)), 
issingle(fstof  st)  -*F(n, rmdof  st), 

iscond(fstof  st)  -*occurs(n,thenof(fstof  st))-*append(F(n,thenof(fsto<  st)), rmdof  st), 
occurs(n,elsoof(istof  st ))-*appo nd(F(n,elsoof (fstof  st)), rmdof  st), 
F(n,rmdof  st), 

isrepwh(fsto<  st)-*occurs(n,bodyof(fstof  st))-*append(F(n,bodyof(fstof  st)),st), 

F(n, rmdof  st), 

isforto(fstof  st)-*occurs(n,bodyof  (fstof  st))-*append(F(n,bodyof(fstof  st)),fortoup(st)), 


The  Semantics  of  PASCAL  in  LCF 


F(n,rmdof  st), 

isfordnffstof  st)-*occurs(n,bodyof(fstof  st)Happend(F(n,bodyof«stof  st)),fordnup(st)), 
F(n,rmdof  st),UU,UU]], 

isvanable  *  [Ax.isname(x)visae(x)], 

isunary  *  [Xx.(x«pplus)v(x*pminu8)v(x=plusl  )v(x«minusl )], 

isbunary  s  [Xx  (x*not)], 

isbinary  s  [Xx  (x=piu5)v(x=minus)v{x=time5)v{x*div)v(x»rmdr)v(x*and)v(x*or)v 
(x*ls«qMx«gr«q)v(x«lt)v(x*gt)v(x«*q)v(x<n«q)], 

isbbinary  s  [Xx  (x«and)v(x*or)], 

isrelop  s  [Xx.(x*lseq)v(x*greq)v(x=lt)v(xsglMx=#q)v(x«noq)]; 


The  Semantics  of  PASCAL  in  LCF 


APPENDIX  3 
THE  SEMANTICS 


3.1  Top  Le  *el  Functions 
AXIOM  TOPSEM: 

FUNCT  *  [Xp  o  i.(INPUT®PASCAL(p,o)«OUTPUT)(i)], 

PASCAL  *  [Xp  o  i.  MP(p,0,FRAME0(p,o,i))]i 

FRAME0  s  [xt  i  o  f.  (f»0)-»[Xloc.(loc=filoloc  INP)  -*  INTERNALREP(i), 

(loc=f ilctoc  OUT)  -*  INTERNALREP(o), 
(loc«textloc)  -*  statmot  t,UNDEF],UU], 

MP  *  [Xt  f.  MD(doclot  t,f)®MS(statmo<  !,<)], 

INPUT  •  ID, 

OUTPUT  *  [ocF.[Xs.[Xi.is*ot  i  -♦EOF, 

ispair  i  -»mkpair(F(tetot  i),F(rmdt><  i)), 
isconst  Hnumot(i),UU](0BUFFER  *)]], 

INTERNALREP  *  [<*F.[Xi.is*of  i  -*E0F, 

ispair  i  -»mkpair(F(tstot  i),F(rmdof  i)), 
isint  i  -amknumconst(i),UU]]i 
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3.2  Declaration  Part 
AXIOM  OECSEM: 

MD  »  [Xd  I.  MDEF(d,f)®MDEC(d,f)], 

MDEF  ■  [«cF  [Xd  f  isamptyst  d  -*  10, 

istypedef  d  -»  CREAT(f,namol  d.typof  d), 
iscmpnd  d  -*  F(fstof  d,f)®F(rmdof  d,f),ID]], 

MDEC  *  [*F.[Xd  f  isemptyst  d  -*  ID, 

isvarded  d  -»  CREAV(f,namof  d.typof  d,<), 
isprocdod  d  -*  CREAP(f,namof  d.prspof  d,<), 
isfunded  d  -*  CREAF(f,namol  d.fnspof  d,typeo<  d,f,f), 
iscmpnd  d  ->  F (fstof  d,f)®F(rmdof  d,f),ID]], 

CREAT  «  [Xf  n  ty  s  CREALOC(f,s,»ypidloc,n,»y)], 

CREAV  *  [Xf  n  ty  <1  s  CREALOC«,s,typeloc,n,TYPEVAL(ty,fl,0)], 

CREAP  *  [Xf  n  ps  fl  s  STOREff ,CRE AL0C(f ,s,acclnk,n,fl), prodoc  n,ps)], 

CREAF  *  [Xf  n  fs  ty  ft  fl  s. 

STORE  (f, STORE (f,CREALOC(f,s,»cclnk,n,fl),typfunloc  n,TYPEVAL(ty,ft,s)),funcloc  n,fs)], 
CREALOC  «  [Xf  t  loc  n  vaUSPRESENT(n,s(f))->UU,$TORE(f,s,loc  n.val)]; 
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3.3  Definition  of  MS 
AXIOM  MSDEF: 


MS?[<F.[Xst  i 

isorptyst  st  -*  ID, 
iscmpnd  st  -* 
isemptyst(fstof  st )— »  F(rmdof  st,f), 

islabstat(fstof  st)-*  F(mkcmpnd(statmof(fslof  st),rmdof  st),f), 
isp,oto(fstof  st)  -*  GOTO(F,labolof (fstof  r.t),f), 

isass  (fstof  st)  ->  ASSIGN(lhr.of (fctof  st),MEXPR(r hsot (fstof  st),f),f)0F(rmdof  st,f), 
isproccall(fstof  st)-*[Xs  MPB(PROCFAL(namof(fstof  st),f,s),adargof(fstof  st),f,s,namof (fstof  st))]Q 
[Xs.MD(PROCDECL(namof(fstof  st),f,s),succ  f,s)]S 
[Xs.F(PROCBODY(namof(fstof  st),f,s),succ  f,s)]®CLEAR(succ  f)®F(rmdof  st,f), 
isread(fstof  st)  -»  READ(namof(fstof  st ),f )®F(rmdof  st,f), 
iswrite(istof  st)  -*  WRITE(namof(fctof  st),f)0F(rmdof  st,f), 
iscond(fstof  st)  -*  COND(MQEXPR (testof (fstof  st),f), 

F(appcnd(thonof  (fstof  st),rmdof  st),f),F(append(elseof(fstof  st),rmdof  st),f)), 
iswhile (fstof  st)  -*  COND(MBEXPR(testof  (fstof  st),f), 

F(append(bodyof (fstof  st),st),f),F(rmdof  st,f)), 
isrepeat(fstof  st)  -*  F(appond(bodyof (fstof  st),mkcmpnd(mkcond(mkbexprl  (not, 
testof  (fstof  st)),fstof  st,ES),rmdof  st  )),f ), 
isforto (fstof  st)  -*  COND(MBEXPR(fortcst  (fstof  sl),f), 

ASSIGN(indoxof  (fstof  st),MEXPR(lbof (fstof  st),f),f)® 

F(append(bodyof(fstof  sO,fortoup  st),f),F(rmdof  st,f)), 
isfordn«stot  st)  -♦  COND(MBEXPR(fortest(fstof  st),f), 

AS$IGN(indexof  (fstof  st),MEXPR(ubof (fstof  st),f),f)® 

F(app«nd(bodyof(fstof  st),fordnup  st),f),F(rmdof  st,f)),  UU,UU]]; 
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3.4  Axioms  for  Statements 


AXIOM  STATSEM: 

READ  *  [Xn  <  s.lSFUNFR(f,s,0)-*ASSIGN(n,MEXPR(fstof(IBUFFER  s),f),f, 

STORE(0,s,fileloc  INP.rmdofflBUFFER  c))),UU], 

WRITE  *  [Xn  f  s,ISFUNFR(f,s,0)-*  ST0RE(0,s,f iloloc  OUT, 

mkpair(mknumconst(FFTCHV(n,<,s)),OBUFFER  i)),UU], 

GOTO  *  [XF.[Xn  <.  F(50gm(n,TEXT«)),l)]], 

ASSIGN  «  [ocF  [Xn  v  f  s 

n=FUNV-»ISADMISVAL(s«,lypcloc  FUNV),v(s))-+STORE(f,spFUNV,v(*)),UU, 

ISINTYPEtn.v.f.sHSTOREtf.s.LOCOFVARtn.f.sJ.vfs)), 

istopf  (f )— *UU, 

ISFUNFR«(s(NEWFP(n1f1s)HF(VARBNDTO(n,tls),v,NEWFP(n,<ls),s),UU]]I 

COND  *  [Xq  1  g  s.(q(s)-»f(s),g(s))], 

MPB  a  [Xfa  aa  f  s  n  BIND(fa,aa,succ  f, 

MAKFRAME(PROCBODY(n,<Is),PFLNK{n,<)s),suce  l,s))], 


CLEAR  *  [Xf  s  fl .«l*f)-»UU,s«l )]; 
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3.5  Binding  Mechanism 
AXIOM  BINDINGS: 

BIND  i  [ocF  [Mi  aa  f  s. 

isecf  fa  -»  (iseof  aa  -»  s,UU), 

isparameter(fstof  fa)-*F(rmdof  fa.rmdof  aa,f,MKBINDING(fstof  fa,fstof  aa,f,s)),UU]], 
MKBINDING  *  [Ma  a  a  f  s. 

isvarp(fa)  -*  TYMATCH(fa,typolcc,aa,f,s)  -»CREALOC(f,s,bmdloc,namof  fa,EXPRFORV(aa)),UU, 
isvalp(fa)  -»  ASSIGN(namof  fa,MEXPR(aa,f),f,CREAV(f,nanr,'>f  fa.typof  fa,CRNTF(f,s),s)), 
isfunp(fa)  -*  TYMATCHMa.typfunloc.da.hs)  -» 

CREAF{f,namof  fa,FUNCDEF{aa,«,s),typof  «a,CRNTF{«,s),PFLINK(aa,f ,s),s),UU, 
isprocp(fa)-*  CREAP(f,namof  fa,PROCDEF(aa,f ,s),PFLINK(aa,f ,c),s),UU], 

TYMATCIi  *  [Xfa  loc  aa  f  s.TYPEVAL(typof  fa,CRNTF(f,s),s)=TYPEDEF(loe  aa.prad  f,s)], 

TYPEVAL  *  [*F.[\n  f  s. 

isbasetype  n  -»  n, 

isarspec  n  -»  mkarspec(F(arlimof  n,f,s),F(typelof  n,f,s)), 

istyppart  n  -♦  iseof  n  -♦  n,ispair  n  -*  mkpair{F(fstof  n,f,s),F(rmdof  n,f,s)),UU, 

iSLOCAKtypidloc  n,s(f ))-»F(s(f,typidloc  n),f,s), 

istopf  «  -*  UU,F(n,CRNTF(f,s)1s)]]; 
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3.6  Evaluation  of  Expressions 
AXIOM  EXPRESSIONS: 

MEXPR  *  [*F.[Xa  f  «. 

itconst  a  -*  MCONST  a, 
isvariable  e  -»  FETCHVfo,!,*), 

isfundes  a  -»  RETURN(jucc  f,MF(namof  a.actargof  e,(,s)), 
isexpr  e  -nsunary(opo<  e)  -»  MOPKopof  o,F(arg  1  of  a,f,s)), 

i«binary(opof  a)->  MOP2(opo<  e,F(arglof  a,f,s),F(arg2of  a,f,s)),UU,UU]], 

MF  *  [Xn  a  f.  MFB(FUNCFAL(n,f)1a1l(n)©MP(FUNCDEF(n,l),succ  f)], 

MFB  *  [Xfa  aa  I  n  «.BIND(fa,aa,*ucc  f.CREALOCUucc  f,typeloc,FUNV,TYPEDEF(n,f,*), 
MAKFRAME(FUNCBODY(nlf,s),PFLNK(n1l,s),succ  f,t)  ))], 

MBEXPR  £  [ocF.fXe  I  s. 

(a*true)-»TT,(e=lalsa)-*FF, 

isbexpr  e  ->isbunary(bopof  o)  -*  MBOPKbopof  a,F(barglof  a,«,s)), 

isbbinary(bopo«  •)-*  MB0P2(bopof  e,F(barglof  e,f,s),F(barg2of  a,f,s)), 
isralop(bopof  a)-*RELOP(boPof  a,MEXPR(arglof  a,f,s),MEXPR(arg2ol  •,<,*»,UU,UU]]1 

MCONST  *  [Xx.itconst  x  -»  numof  x,UU], 

MOP1  *  [Xx.xspplus->Xx.x,x«pminus->Xx.(0-x),x«plus  1  -*succ.x»minusl  -*prad.UUl. 

MBOP1  *  [Xx.x*nol-*'1UU], 

MOP2  *  [Xx.xsplus-»!*,x=minus-»!”)x*limes-»!*,x*div-*!/1x*rmdr-*mod,UU], 

MBOP2  £  [Xx^and-^lA.xsor-ilViULI], 

RELOP  £  [Xx.x«lsaq-*!<)x«graq-*!>)x*lt-+!<(x*gt-»!>,x«eq-»!s,x*n#q-*/,UU]; 
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3.7  Variables 


AXIOM  VARIABLES: 

NAMOrVAR  «  [Xv.n=FUNV->UU,isname  v-*v,isaa  v-*namof  v,UU], 

LOCOFVAR  *  [Xv  f  s.isname  v-»v,isae  v-»arloc(namof  v,VAL(subof  v,«,s)),UU], 
TYPOFVAR  *  [Xv  f  s.isnamo  v^TYPEOFW.sJ.isa*  v-*typolof(TYPEOF(namof  v,f,s)),UU], 
EXPRFORV  «  [Xv  f  s.isnam#  v-*v,isae  v-*mkae{namof  v,EXPRVAL(subof  v)),UU], 
VARBNDTO  *  [Xv  f  s.l$BND(NAMOFVAR  v.f.sH 
isname  v  -*  BVALOF(v,l,s), 

isa*  v  mka«(BVALOF(namof  v,f,s),subof  vUJU.v], 


ISINTYPE 


«  [Xv  val  f  s.ISLOCAUtypeloe  NAM0FVAR(v),s(f)5  -» 

ISAOMISVAL(TYPOFVAR(v,f,s),val(s)),FF], 


ISADMISVAL  *  [Xly  v.ity«INT)-*i*int  v,is*ublim  ty-*lSINBOUND(v,ty),UU], 


ISINBOUND  s[*F.[Xxy. 

isaof  x  -*  TT, 

ispair  x  -♦  F (fstof  x.fslof  y)AF(rmdof  x.rmdof  y), 

isint  x  -*  issublim  y-»(x£numof(lbof  y))A(x<numof(ubof  y ) ) ,UU,UU J J, 

VAL  «  [o«F.[Xp  is. 

issof  p  -*  EOF, 

ispair  p  -♦  mkpair(MEXPR((sto<  p,f,s),F(rmdof  p,f,s)),UU]], 

EXPRVAL  «  [«cF.[Xp  1  s. 

ispair  p  *+  mkpair(mknumconst(MEXPR(frstof  p,l,s)),F(rmdof  p,f,s)),UU]]; 
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3.8  The  Lookup  of  the  Store 

AXIOM  LOOKUP: 

IBUFFER  =  [Xs.s(0,filoloc  INP)], 

OBUFFER  *  [Xs  s(0,filoloc  OUT)], 

TEXT  a  [Xf  s.s(f,tcxtloc)], 

PROCDEF  *  [Xn  f  s.FETCHfprodoc  n,f,s)), 

FUNCDEF  3  [xn  f  s.FETCH(fundoc  n,f,s)], 

TYPEDEF  3  [Xloe  f  s.FETCH<loc,f,s)), 

PROCTXT  «  [Xn  f  6.tex{oi(PROCDEF(n,f,s))]l 
FUNCTXT  *  [Xn  f  s  tex‘of{FUNCDEF(n,f,s))], 

PROCFAL  s  [Xn  f  s.fargof{PROCOEF(n,<,s))], 

FUNCFAL  3  [\n  f  s.fargof (FUNCDEF{n,(,s))], 

PROCOODY  3  [Xn  f  sstatmoflPROCTXTIn.f.s))], 

FUNCBODY  s  [Xn  «  s  statmoMFUNCTXTfn.f.s))], 

PROCDECL  *  [Xn  f  s.didof(PROCTXT(n,f,s))j, 

FUNCDECL  3  [Xn  f  s.dadoffFUNCTXTfn.f.s))], 

PFLNK  3  [Xn  f  s.  FETCH(aednk  n.f.s)], 

NEWFP  3  [xn  <  s.  ISBNO(NAMOFVAR  v,f,s)-»  pred  f,CRNTF(f,s)], 

CRNTF  «  [Xf  s.  s(f,alnk)], 

FETCH  3  [ocF.[XI  f  s.lSLOCAL(l,s{f ))— *s(f,l),istopf (f)-*UU,F (I.CRNTF (f|S),s))), 
FETCHV  3  [*F.[Xn  f  s.ISLOCALftypeloc  NAMOFVAR(n),s(f))-* 

ISLOCAL{NAMOFVAR(n)1s(f)Hs«,LOCOFVAR(n,f,s))1UU, 

istopf«)-*UU1F(VARBNOTO(n)f,$),NEWFP(n,<I5)1s)]], 


TYPEOF  3  [xn  »  s.sff.typeloc  n)], 
BVALOF  *  [Xn  f  s.s(f,bindloc  n)]; 
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3.9  Updating  and  Miscellaneous  Axioms 


AXIOM  UF  3ATE: 


STORE  B  [XI  s  loc  val.[Xf  1  .f  1  *f-+M0DFR AME(s(f ),loc,val),s(f  1 )]], 
MODFRAME  B  [XI  loc  val.[Xlocl  loci -loc-+val,l(loc  1 )]], 

MAKFRAME  «  [Xtxl  In  I  s.[Xll  .1 1  «l-+[Xloc  1  loc  1  ■t«xtloc-+txt,loc  1  »alnK 


ln,UNDEF],s  (1 1 )]]; 


AXIOM  FRAME: 

Irama  *  [Xs  l.s(l)], 
istopl  =  [XI  (1*0)]; 

AXIOM  AUXSEM: 

!®  *  [XI  A  r.jdlr))], 

ISFUNFR  t«<F  [XI  s  nl.  ISlOCAL(FUNV,s(!))-»  FF.prad  l«nl  -+  TT,F(prad  f,«,nl)]], 
ISLOCAL  *  [Xloc  lr.lr(loc)«UNDEF-+FF,TT], 

ISPRESENT  *  [Xn  Ir.isname  n-*ISLOCAL(lypidloc  n,lr)vlSLOCAL(typ*loc  n,lr)v 

ISLOCAUacdnk  n,lr)vlSLOCAL(bindloc  n,«r),UU], 
RETURN  •  [XI  *.ISLOCAL(FUNV,s(l))-«(l,FUNV),UU], 

ISBND  B  [Xn  s  I.ISLOCAL(bindloc  n,s(l))]; 
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APPENDIX  4 

Proof  of  the  equivalence  involving  WHILE  for  goto-free  programs 


4.1  List  of  LCF  commands 


TRY  1  INDUCT  -j 
TRY  1  SPREF ; 

LABEL  INDUCT; 

TRY  2  SPREF i 
USE  GOTOFj 

RPPL  -  ,  S,i«'  cmpnd  (hkuhi  I*  ( t  ,SI  ,ES) ,  I ; 
LABEL  HELP; 

SIMPL  -  BY  GOTOFlj 
APPL  .  INOUCT, S, t , « ; 

SIMPL 
USE  C0N01 

APPL  -.MBEXPRI »,  f >  ,S; 

SIMPL 
SS+. HELP; 

TRY  SSUBST  .MSFP  OCC  3; 

TRY  ; 0E0; 
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4.2  Printout  of  the  proof 


|  TRY  » 1  VS  t  I  .  i sgoto tree  (5)  n  UH1*_L  (MBEXPR  It,  t)  ,I1S  (S,  M )  c  US  (mkcmpnd  Imluh  i  led  ,S>  ,ESI ,  f  >  INDUCT  331  - 

[  (TRY  #1#1  VS  t  t  ,  Isgotofree <S>  :  i  UU  (HBEXPR  ( t ,  I > ,MS(S, 1 1 1  c  MS  (mkcmpndtml  wh  i  le  ( t  S),ES),t)  SPREP. 

|  1 332  VS  t  t  .  isgoto tree (S)  n  UU  (MBEXPR  (t,t>,f1S(S,1>)  c  MS  (ml  cmpnd  (ml  uhi le(t ,S)  ,ES) ,  f )  —  SPREF  B'  . 

I  . - . 

|  |  TRY  M1M2  VS  t  t  .  Isgotolree(S)  is  txt  b  .CONO  C  t ,  b«F  (t  ,b> ,  1 D)  I  (MBEXPR  (t,  t) ,  US  (S ,  f ) )  c  MS  (mkcmpnd  (mt  uh 1 1 • ( t  * 
,S),ES),I)  t  ASSUME  VS  t  t  .  isgotofree <S)  ::  F  (MBEXPR  ( t ,  I ) ,  MS  (S,  t) )  c  MS  (mkcmpnd  (mkuh  i  le  ( t  ,S>  ,ES> ,  t )  SPRE* 
F. 

|  1 333  VS  t  f  .  isgototree(S)  is  F (MBEXPR  (t ,  t ) ,MS(S, () >  c  MS (mkcmpnd (mkuhl le (t ,  S)  ,ES) , t )  (333) - ASSUME. 

|  1 334  i sgo to  tree  (S)  t  TT  (334)  —  SRSSUME. 

|  |33S  VS  P  f  ■  isgotofree(S)  n  isgototree (F>  u  MS  (append  (3,  P) ,  t>  £  MS  <S ,  OuMSfP,  t)  - USE  GOTOF, 

1 336  txS  P  f  .  i  sgo  tofree  (S)  *(  isgo  to  tree  (P)  -*MS  (append  (S  ,P> ,  t ),  UU) ,  UU1  (S,  »l  cmpnd  (mi  uh  i  le  ( t ,  S ),  ES) ,  t )  e  txS  P  * 

t  .  isgotofree(S)*(  isqotofree  (P)«(MS<S,  OwMSlP,  f  )>  ,UU>  ,UU1  (S.mkcmpndfmkHhi  le(t,S),ES> ,  t>  - RPPL  33S  S  mkcmpnd* 

(mk uh i  le  ( t , S) , ES)  t . 

|  |  j  J?  MS  (append  (S,  mlciopiid  (rnl-h  I  !c  ( t ,  S) ,  E$) ) , ! )  *  M3  (4 ,  f  >uM5  (mi  cmnnd  (mkuhl le (t , S) , ES ) , I )  (334) - SU1PL  336* 

BY  33  GOTOF 1  . 

|  |3’i  (XS  t  I  .  isgotofree (S)«F (MBEXPR (t , I) ,MS  (S, t) ) ,UU1 (S,  t ,  I )  e  txS  t  f  . isgotofree  (S)*MS  (mkcmpnd  (ml  uh  i le 1 1* 
, S) , E 3) ,  I ) , UU 1 (S , t ,  I)  (333)  —  RPPL  333  S  t  f. 

|  1 339  F  (MBEXPR  1 1 , t ) , MS  <S , t ) )  c  MS (mkcmpnd (ml uh ile(t,S),ES),f)  (333  334)  —  SIMPL  338  BY  334  . 

|  1 3  4  0  VT  SI  .  CONO  (T,  MS  (SI,  t)«F  (MBEXPR  ( t ,  f ) ,  MS  (S,  f)> ,  10)  c  CONO  CT.MS  (SI  DetlS  (mkcmpnd  (ml  wh  i  le  1 1  ,S>  ,  ES )  ,  f ),  10* 

)  (333  334)  —  USE  C0N0I  339. 

|  1 34 1  (XT  31  .CONO  <T , MS  <31 ,  t )  vF  (MBEXPR  (t ,  t )  ,MS  (S,  I) ) ,  10) )  (MBEXPR  1 1 ,  f )  ,S)  c  (XT  SI  .  CONO  (T,  MS  (SI ,  DellS  tmkcmpn* 
d  (mki’i  ile(t,S),E3),f),10>)  (MBEXPR  (t ,  f )  ,S)  (33S  334)  —  RPPL  340  UBEKPRl  t ,  t )  S. 

|  1 342  CONO  (MBEXPR  <  t ,  t  > ,  MS  (3 ,  t  >  »:F  (MBEXPR  ( t ,  t)  MS  (S ,  f ) ) ,  ID)  c  CONO  (MBEXPR  ( t ,  t) ,  MS  (S ,  I )  >:IIS  (ml  cmpnd  (mk  uh  i  le  ( t ,  S)  * 
,ES> ,  f ) , IC)  <333  3341  —  SIMPL  341. 

|  |  |  TRY  COMO  (IIBEXPRIt,  I)  ,MS(S,  f  )*F  (MBEXPR  ( t ,  I)  ,MS  (S,  t) ) ,  10)  c  MS  (ml  cmpnd  (ml  uhi  le  (t ,  S)  ,ES) ,  < )  SSUB* 

ST  320  0CC  3. 

j  I  TRY  CONO (MBEXPR  <  t ,  t ) , MS  < S , t  > »F (MBEXPR  <1 , t ) , MS (S , f ) ) , » 0 >  c  CDND (MBEXPR  ( t ,  t ) ,  MS  (S ,  t ) »MS  (ml  cmpnd* 

(mk wh i I e ( t , S I ,ES) , f I , 10)  . 


|  |  j  343  CONO (MBEXPR ( t , f ) ,MS(S, t )«F (MBEXPR (t , I ) ,MS(S, I ) ) , 10)  c  MS  (ml  cmpnd (mi uhi le(t,S),ES),f)  (333  334) - * 

SSUBST  342  USING  320  0CC  3. 

I  I  . 

|  1 344  VS  t  t  .  isgototree(S)  : ;  txt  b  .  CONO  ( t  ,b*F  (t,b) ,  10)1  (MBEXPRd ,  t)  ,NS(S,  1 1 1  c  MS  (mkcmpnd  (lekuh  i  le  (t  ,S> ,  E* 
S) , t)  <3331  —  SPREF  343. 


|34S  VS  t  I  .  Isgotofree (S)  i:  WHILE (MBEXPR  <t ,  t), MS  (S, i> )  c  MS (mkcmpnd (mk wh I  le(t,S),ES),f)  —  INDUCT  332  3* 

44. 
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APPENDIX  5 


Proof  of  the  equivalence  involving  REPEAT  for  goto-free  programs 


5.1  Li)(  of  LCF  commands 


TRY  1  INOUCT 
TRY  1  SPREFj 

LABEL  INDUCT) 

TRY  2  SPREFj 
USE  GOTOF; 

APPL  -  .S.mkcmpnd (mkeond  nkbaxprl (nol , () ,»kr«p»« t IS, t ),ES)  ,ES) ,  I  | 
LABEL  HELP; 

SIHPL  -  BY  GOTOF 1 ; 

APPL  . INDUCT, S, t , < i 

SIPPL 

USE  C0NP1 

APPL  - , HBEXPR (mkbaxprl (not,  t ) ,  I ) , S; 

SIHPL 

SS+.HELP; 

TRY  SSUBST  . HSFP  OCC  3; 

TRY  SSUBST  .HSFP  OCC  4| 

TRY  ; QEO; 
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5.2  Printout  of  the  proof 


|  TR  Y  1 1  VS  t  I  .  iigotolree(S)  :i  REPEATIMS  <$,  t )  .MBEXPR  (ml  bexprl  (not,  t) ,  I) )  c  MS  (ml.  cmpnd  (mV  ropea  t  (S,  1 )  ,ES>  ,  I )  » 
INDUCT  331  . 


|  |  TRY  >\t\  VS  I  t  i  i*gotolree(S)  ::  UU (MS  <S, I ) .HBEXPR  (mi  bexprl (not,  I) ,  I ) )  c  MS(mkcmpnd  (mkrepeat  (S,  t) ,  ES)  ,  I  >  % 
SPREF. 

|  1 332  VS  1  I  .  itgotolree(S)  ::  UU(MS  <S,  t)  .HBEXPR  (mkbexprl  (not ,  I ) ,  I) )  c  MS  (mk  cmpnd  ( mk  repeat  (S,  t)  ,ES),  f)  _ .. 

-  SPREF  BY  . 


|  I  TRY  »\H2  VS  I  I  .  ifgotolree(S)  s:  US  t  .beCDND  (t  ,F  (b,  1) ,  ID)  IIMSIS,  I)  .HBEXPR  (mkbexprl  (not ,  1 ) ,  I)  )  c  MSIrnkc- 
mpnd  (mkrepeat  <S,  I )  ,ES) ,  ()  !  ASSUME  VS  I  t  .  i  tgotolree(S)  : :  F  (MS  (S,  I ) ,  HBEXPR  (mkbexpr  1  (no  1 , 1  > ,  I ) )  c  HS(mKcmpnd~ 
(mkrepeat <S, 1 ) ,ES) ,  I )  SPREF. 

|  1 333  VS  t  t  .  itgotolree  S)  is  F  <MS(S,  t ) ,  MBEXPR  (mkbexprl  (not,  t) ,  I) )  c  MS  (mkcmpndlmlrepeat  (S,  1 )  ,ES>  ,  I )  (333~ 

)  ASSUME. 

|  1 334  i*gotofree(S>  s  TT  <330  —  SASSUME . 

I  j  33S  VS  P  <  .  i sgoto I ree (S)  :i  i igoto Iree <P>  !!  HS  (Append  IS,  P) ,  r )  i  MS(S,  OuMS  <P,  U  - USE  GOTOF. 

|  j 336  JxS  P  I  .  i*gotofree(S)-*<  isgotolree  (P ) -MS (append (S, P ) ,  I) , UU) , UU)  <S,mkcmpnd(mkcond(mkbexprl  (not ,  I)  ,mkrep«. 
eat  <S,  t)  ,ES)  ,ES) ,  <)  =  US  P  I  .isgotolrco(3)-*<  isgotolree  (P> ■•(MSIS,  lUMSIP,  I)  >  ,UU)  ,UU)  (S.mi  cmpnd  (ml cond (mkbexprl  (* 
not , t ) .mkrepeat <S, t) ,ES) ,ES>  ,  I)  —  APPL  335  S  mk  cmpnd  (mkcond  (ml  bexprl  (not ,  t )  .mk-opoat  (S,  t )  ,ES)  ,ES)  (. 

|  1 337  MS  (append (S.mkcmpndlmkcond  (mi bexprl  (not ,  t> ,mk repeat (S, t)  ,ES>  ,ES> ),  I )  :  MS  (S,  I )  nM3  (ml.  cmpnd  (ml  cond  (rnkbex* 

prl  (not,  t)  , mi  repeat  <S,  t),ES)  ,ES) ,  n  <330  —  SIMPL  336  BY  334  GDTDF1  . 

|  1 336  JxS  t  I  .  isgotolree  <S)  »F  (MS(S,  (),  MBEXPR(mkbe*prl  (not,  t) ,  t) )  ,UU)  (S,  t ,  ()  c  I xS  t  I  .  isgotolree  (S)  -*MS  (mkc~ 

mpnd  (mkrepeat (S, t) ,ES> , I) , UU) (S, t ,  I)  (333)  —  APPL  333  S  t  (. 

|  j  339  F  (MS  <S,  I)  (HBEXPR  (ml  bexprl  (not ,  t) ,  I) )  c  MS(«i  cmpnd  (ml  repeat  (S,  t)  ,ES) ,  I)  (333  330  —  SIMPL  338  BY  334 ~ 

|  1 34  D  VT  St  .  MS  (SI,  OxCONO  (T,F  (HS(S,  I)  .HBEXPR  (ml  bexprl (not,  t) ,  I) ) ,  ID)  c  MS  (SI,  I)  xCONO  (T.MS  (ml  cmpr.d  (ml  repea  t« 

<S,  t)  ,ES) ,  I) ,  10)  <333  330  —  USE  C0N01  333. 

|  |  34 1  JXT  SI  .MS  (SI,  OkCONDIT.F  (MS(S,  I) ,  MBEXPR  (ml.  bexprl  (not,  t) ,  I) ) ,  ID))  (MBEXPR  (mk  be  »prl  (not ,  t ) ,  I )  ,  S)  c  UT  S. 

1  .  MS  (SI ,  OwCOND  < T , MS  (mk cmpnd (mkrepoat  (S,  t)  ,ES) ,  I)  ,10))  (MBEXPR (ml: bo> prl  (not ,  t) ,  I) ,  S)  (333  334)  ---  APPL  340  MBE  * 

XPR (ml boxprl (not , t ) , I)  S. 

|  |  342  MS<S,l)*iCDND(MBEXPR(mkbovprl<not,t  ,  I)  ,f  (MS  (S,  I  >  ,  MBEXPR  (ml  bexprl  (no 1 ,  t)  ,  I )  ) ,  )D)  c  MS  (S,  I  >  kCONO  (MBEXPR  U 
mkbexpr  1  (no  t ,  t ),  I )  ,MS(mkcmpnd(mkrepeat  <S,  t)  ,ES1  , 1) ,  )D)  (333  334)  —  SIMPL  341. 


|  j  |  TRY  IW2fl  MS(S,  l)*CDNO  (MBEXPR  (ml  bexprl  (not,  t ) ,  I)  ,F  (MS <S,  I)  .MBEXPR  (mk bexprl  (no t ,  t )  ,  I ) ) ,  10)  c  MS  (ml  cmpnd  U 
mk repoa t <S , t ) , ES) ,  I )  SSUBST  320  DCC  3. 


|  |  |  |  TRY  MS  <S,  I )  *COND (MBEXPR  (ml  bexpr  1  (not ,  t ) ,  I ) ,  F  (MS  (S,  I )  ,MBEXPR  (mkbexpr  1  ( no  t,t),()),JO)  c  MS(S,()~ 

«MS  (mkcmpnd  (mkcond  (ml  bexprl  (not ,  t)  .mkrepeat  (S,  t )  ,ES) , ES) ,  I)  SSUBST  320  DCC  4. 


|  |  |  |  I  TRY  tnf2*mei  MS(S,I)*CDND  HBEXPR  (mkbexprl  (not ,  t ) ,  I ) ,  F  (MS  <S,  I  >  .HBEXPR  (mkbexpr  1  (no  t ,  t ) ,  I ) ) ,  JO)  c  MS  ( ~ 
S ,  I )  mCOND  (MBEXPR  (ml  bexprl  (no  t ,  t ) ,  I )  , MS  (ml  cmpnd  (mk repea  t  (S,  t) , ES) ,  I) ,  ID) 


|  |  |  1 343  MS  (S,  I  leCDND (MBEXPR  (mkbe.pr  1  (not,  t) ,  I)  ,F  (MS <S,  I)  .MBEXPR (ml bexprl  (not,  t ) ,  I) ) ,  ID)  c  MS  (S,  I )  kHS  (mkcmp- 
nd  (mk  cond  (mkbexpr  lino  t ,  t ) , mkrepeat  (S,  t ) ,  ES  J  ,ES> ,  I )  (333  334)  SSUBST  342  USING  32D  OCC  4. 


|  |  1 344  MS  (S ,  I )  kCDND  (MBEXPR  (ml  bexprl  (not ,  t ) ,  I)  ,F  (MS  (S,  I ) , MBEXPR  (mkbexpr  1  (not ,  t ) ,  I ) )  ,  ID)  c  MS  (mkcmpnd  (ml  repea- 
t(S,t),ES),()  <333  334)  —  SSUBST  343  USING  328  DCC  3. 


|  |  34S  VS  t  I  .  isgotoIree(S)  ::  Ub  t  . bxCONDft ,F  (b,  t) ,  10)1  (MS  <S ,  I)  .MBEXPR  (ml  bexprl  (not ,  t ) ,  I) )  c  MSImkcmpndU 
mkrepeat <S, t) , ES ) ,  I)  (333)  —  SPREF  344. 


|346  VS  t  I  .  isqotolree(S)  i:  REPEAT(M3(S,  I)  .MBEXPR  (ml  bexprl  (not ,  t) ,  I  )  c  MS  (ml  cmpnd  (mkropea  t  ( S ,  t )  ,E  ,)  ,  I ) 
—  INOUCT  332  345. 
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APPENDIX  6 

Proof  of  the  equivalence  involving'  FORTO  for  goto-free  programs 


6.1  Li‘t  of  LCF  commands 


TRY  1  INOUCT  -| 

TRY  1  SPREF| 

LABEL  INOUCT-, 

TRY  2  SPPCFj 
USE  GOTGF; 

APPL  -  ,S,mrcmpnd(inMorto(l,tiik«s.prl(pluil,i)l«2)S)1ES)  ,tj 
LABEL  HELP ; 

SIMPL  -  ; 

APPL  .  INOUCT.S,  l.mHyprltplusl,  f  j 

SIMPL 

USE  CONDI  -i 

APPL  - , MBEXPR (mkre I ( I s«q,«,*2) ,() ,S, ASSIGN ( i ,MEX >R (»,«), t ) ; 

SIMPL 

SS  +  . HELP  j 

TRY  SSUBST  . MSFP  OCC  3; 

TRY  ; QEO ; 
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6.2  Printout  of  the  proof 


|  TRY  #1  VS  *  el  e2  I  .  isgotolree(S)  ::  FDRTOf  i  ,el  ,e2,MS  (S,  I ) ,  I)  c  US  (mkcmpnd  (ml.  lorto  ( i  ,al ,  e2,  S)  ,ES ) ,  > )  1. 

NDUCT  304  . 


|  | TRY  #1#1  VS  i  el  e2  I  .  isgotofroe(S)  n  UU <  i  ,*1, e2,MS  (S,  I) ,  I)  c  MSIm*  cmpnd (mb  lorto ( i  ,el,e2,S)  ,ES ) ,  I ) 

SPREF. 

|  1 3  05  VS  i  el  e2  I  .  isgotolree  ($)  ::  UU  <  I ,  al,e2,MS  (S,  I ) ,  I )  c  MS  (mkcmpnd  (n*  lor  to  ( i  ,el,e2,  S I  ,ES  I .  * )  —  SPR. 

EF  BV  . 


|  j TRY  #1#2  VS  i  •  e2  I  .  isgotolreefS)  it  t A i  •  i2  b  I  . CDNDIMBEXPR (mkra  I  ( >seq,e, e2) ,  I ) ,  (ASS 1GN 1 1 , tlEXPR  (e ,  I )  . 
,  I ) mb)  *F  <  i , mkexprl (p lus 1 ,  i > ,e2,b, I ) , !D)1 ( i ,e,e2, MS (S, I ) , I )  c  MS  (in*  cmpnd  (ml  lor  to  I  i ,  a  ,e2 , 3) ,  ES)  ,  I  >  i  ASSUME  VS  i. 
a  e2  I  .  i  sgo to (raa  (SI  i:  F ( i , a , t2 , MS (S, ( > , I )  c  MS (mkcmpnd  (mk  lorto I i ,a,a2,S)  ,ES) ,  I )  SPREF. 

|  1 3  06  VS  i  a  e2  I  .  IsgotolreelS)  ::  F  ( *  ,a,a2,MS(S,  I) ,  I)  c  MS  (mkcmpnd  (r.K  lor  to  ( i  ,a  ,e2,S)  ,ES) ,  I )  (306)  — -  AS. 

SUME. 

|  1 307  isgotolree  (S)  =  TT  (307)  —  SASSUME. 

|  1 308  VS  P  I  .  isgotofree(S)  :t  isgotolrne(P)  ::  MS (appendlS.P) ,  I)  i  MS (S , I >i:MS  IP,  I )  —  USE  GDtDF  . 

|  j  3 09  t.\S  P  I  .  isgotolree  <S)<(  i  sqotolree  (P)-*MS  (append  (S,P> ,  I )  ,UU)  ,UU)  (S, mkcmpnd  (ml  lor  to  ( i ,  mk  expr  1  <p  I  us  1 ,  i  >,  e. 

2, 3)  ,ES )  ,  I )  *  t,\S  P  (  .  isgotolree  (S)  ■•(  isgotolree  (P).(MS  (S,  I HTIS  (P,  (>)  ,UU)  ,UU)  IS  ,m*  cmpnd  (ml  lor  to  ( i ,  ml  exprl  (p  lusl , . 

i )  , e2,  S)  ,ES )  ,  I )  - APPL  308  S  ml  cmpndlml  lor  to<  i  ,m*  exprllplusl,  i )  ,e2,S)  ,ES>  I. 

|  |310  MS  (append  (5,  m*  cmpnd  (m*  loi  to  ( i  ,ml  opr  1  (plusl,  i )  ,o2,3) ,  ES) ) ,  I)  t  MS  (S ,  I ) kMS  (mk  cmpnd  (m*  lor  t o  ( I ,  mk  expr  1  (p  I . 

usl,  i),r2,S),ES),l)  (307)  —  SIMP!  309  BY  307  GDTDF1  . 

|  1 3 1 1  t aS  i  a  e2  I  .  i sqoto tree (S) -F  1 1  ,o,e2,(IS (S,  I > ,  I >  ,UUl  IS, i ,m*  e-pr 1 (p lusl , i ) ,e2 , 1 >  c  US  i  e  e2  I  .isgotol. 
r  ee  (3 ) -*MS  Imk  cmpnd  fmk  lor  to  ( • ,  e,e2,S>  ,ES> ,  I  >  ,UU)  (S,  i  ,m*  a  .prl  (plusl,  i  >  ,e2, 1)  (306)  ---  APPL  306  S  i  mke,-.pr  1  (p  lusl ,  * 

■ )  e2  I . 

|  |312  F 1 1 ,ml  exprl (plusl, *> ,e2,MS<3, 1) , I)  c  MS (mkcmpnd (m* lor  to!  i  ,mi  e>prl  Ip lusl, i ) , o2, S) ,  ES ) ,  I )  (306  307) - . 

SIMPL  311  BY  307  . 

|  |  313  VT  SI  H  .  CDNDU,  (HvMS  (Si ,  I ) )  vF  ( i , mkaxprl  (p  I usl ,  I )  ,e2,MS  (S,  I ) ,  I ) ,  ID)  c  CDND  (T , H*  (MS  (S 1 ,  I )  xMS  (in*  cmpnd  (m. 
k  I  or  to  ( *  ,mk  expr 1 (plusl, I ) ,e2,S> ,ES> , I) > , ID)  (306  307)  —  USE  CDND 1  312. 

|  1 3 14  UT  SI  H  .  CCNOIT,  (HxMS  (SI ,  I )  l  .F  ( i , mka'prl  (p lusl,  i ) , n2,M5 (S,  I ) ,  I ) ,  10)  1  (MBEXPR  (ml  re  I  <  Iseq,  o ,  e2) ,  I )  .  S ,  ASS* 
IGNIi  ,MEXPR(e,  I) ,  ID  c  [At  SI  H  .  CDND  (T,H*(MS  (31,  l)»MS  lm*  cmpnd  (mk  lor  tol  I  .mkexprl  (p  lusl,  I ) ,  a2,  S ) ,  ES ) ,  III  ,  10)1  <  MBE  ~ 
XPR(m*rel(lsaq,e,»2),l),S,  ASSIGN  (i  ,I1EXPR  (a,  I ) ,  I ) )  (306  307)  —  APPL  313  MBEXPR  (ml  rol  (Iscq,e,a2)  ,  *)  S  ASSIGN!,,. 

MEXPRIe,  I),  I). 

|  1 315  CDND  (MBEXPR  (mkra  1 1 1 seq, o, a2) ,  I ) ,  (ASSIGN  ( i , ME XPR  (e,  I ) ,  I  )*IIS (3, 1) ) ttF  ( I  ,mk expr  1  (plusl ,  i  > ,  e2,MS  IS ,  I )  ,  I ) ,  ID. 
)  c  CDND  (MBEXPR  Iml  re  I  <  Is#q,e,a2) ,  I )  .ASSIGN!  *  ,MEXPR  (a ,  I ) ,  I )  x  (MS  (S,  I  IxllS  (mkcmpnd  (mk lor  to ( i , mk expr 1 (p I  us  1 , *  > ,e2, S > ,  . 
ES) , I ) ) ,  ID)  (306  307)  —  SIMPL  314. 


|  I  |  TRY  #imi  C0ND  (MBEXPR  (ml  rol  ( lseq,o,e2> ,  I ) ,  (ASSIGN  ( i ,  MEXPRIe,  I) ,  l)«MS  ($, I) )«F  ( i  ,  mkexprl  (plusl, i), e2, MS (S. 
,11,11,10)  c  MS  (ml  cmpndlmk lor  tot i ,a,e2,S) ,ES) , I)  SSUBST  293  0CC  3. 


|  |  |  |  TRY  CDND  (MBEXPR  (mkra  I  ( Iseq,e,e2) ,  I) ,  (ASSIGN!  i  .MFXPRIa,  I) ,  DkMS  (S, III  *eF(i,mk  expr  l(plusl,i),e2,» 

MS(S,  I)  ,  I)  ,  ID)  c  CDND  (MBEXPR  (ml ra  l  ( I  seq, e , a2) , I ) , ASS  1 GN  ( i ,  MEXPR (a, I ) , I ) » (MS  IS,  I) «MS Imk cmpnd (mk  lor  to  ( i  ,mkexprl  (p  I . 
us  1 , * ) ,o2 , S ) , ES) , I ) ) , ID) 


|  |  1 316  CDND  (MBEXPR  (mkra  I  (Iseq,e,e2) ,  >,  (ASSIGN!  i  .MEXPRIe,  I) ,  DsMSIS,  I)  )ttF  ( j  ,mt  evprl  (p  lusl,  * )  ,  e2 , MS  IS ,  I  >  ,  I )  ,  . 
ID)  c  MS  (mkcmpnd  (mk lor  to  I  * , e ,e2, S) , ES ) , I )  (306  307)  —  SSUBST  315  USING  293  DCC  3. 


|  1 3 1 7  VS  i  e  i2  I  .  isgotolreo(S)  s:  I.M  e  e2  b  I  .CDND  (MBEXPR  (mt  re  I  ( I  seq ,  a ,  c2) ,  I ) ,  (ASSIGN  ( i ,  MEXPR  (e ,  I )  ,  I )  Kb. 
) '<F  1 1 ,  im  oxpr  1  Ip lual ,  i )  ,o2,b,  I ) ,  ID))  ( i , e, o2,MS (S,  I ) ,  I)  c  HSImi  cmpndlml  lorto!  i  ,e,e2,S)  ,ES) ,  I)  (306) - SPREF  316. 


1 3 1 8  VS  i  el  a2  I  .  isgotolrea(S)  ::  FORTDI i ,el ,e2,MS (S,  I) , I)  c  MS(mi cmpnd (ml  lor  to  ( i ,  el  ,e2,  S)  ,  ES) ,  I )  - IN. 

DUCT  30b  317. 
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APPENDIX  7 


Proof  of  the  goto-free  factorial  program 


7.1  L! it  of  LCF  commands 

SS*  .  APPLY,  .FUNCT,  .PASCAL,  .IIP,  .FUNCCOflP, .  10,  .DP, .  SP, . MOj 
TRY  S1HPL ; 

TRY  INDUCT  .UHllEj 

TRY  1  SPREF| 

SS  ♦  . COND j  SS  -  .SP| 

LABEL  INDUCT; 

TRY  2  SPREF; 

LABEL  LI  — ; 

TRY  CASES  ; 

TRY  3  S1HPL; 


TRY  2; 

USE  ARITH1  .LI 
QED  -i 

TRY  1  SinPL; 

APPL  .  INDUCT, pr»d  n,x*ni 

StriPL 

TRY  i  OED; 


Btafgufug&i 
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?._»  Piimout  of  the  proof 

tR i  i |  Vn  X  .  isnat(n)  nnat(x)  ::  APPLY (FACTORIAL, n.x)  c  FACTIn, x>  SIMPL. 


|  |1PV  lit  1  Vn  X  .  isnat  (n)  ::  .snat(x)  ::  RESULT  (UR  I TE  (nl.R.UHlLE  (MBEXPR (tost ,0) ,MS(body,0>  .REDD  (nl , O.READ  (n. 

. ,  0,lt\LMV(0,n2,  INT.O.CREAVIO.nl,  I NT, O.FRAMEO  (FACTORIAL,  INPUT  (LIST  (n,x) )  ,E0F) ) ))))))  c  FRCTIn.x)  INDUCT  314  . 


I  I  |  TRY  iltlil  Vn  X  .  isnat(n)  ::  tsnat(x)  is  RESULT  (URITE  (nl  ,0,UU  (MBEXPR I  tost .  0) ,  US  (body ,  0)  .REfiO  (nl ,  0 ,  READ  I. 
n2.O,CREAV(0.n2,  INT.O.CREAVIO.nl,  INT,  O.FRAMEO  (FACTORIAL,  INPUT  (L  1ST  (n,x) )  .EOF) ) ))))))  c  FRCTIn.x)  SPREF. 

I  I  |318  Vn  X  .  isnat(n)  :■  isnOtU)  ::  RESULT  (URITE  (nl, 0, UUIMBEXPRItost, 0), HS(body, 0)  ,REA0(nl,O, READ(n2, 8, CR. 
EAV (0,n2, INT, 0, CREAVId.nl , INT, O.FRAMEO (FACTORIAL, INPUT (LlST(n.x)) ,E0F) ) ) ) I) I)  e  FACT(n.x)  —  SPREF  BY  TH8  TH6. 


|  |  |  TRY  rltliZ  Vn  x  .  isnat(n)  ::  isnat(>)  s:  RESULT  (WRITE  (nl ,  0,  Ixt  b  .CONDI  t  ,b*F  (t  ,b> .  10)1  (MBEXPR  <  lest ,  0) ,  M* 
S  (body,  0)  .READ  (nl.0,READ(n2,8,CREAV<O,r.2,  lNT,0,CREAV(0,nl,  INT, O.FRAMEO (FACTORIAL, INPUT  (LIST  (n.x) )  ,E0F ))))))))  c  - 
F  AC  Tin,.)  :  ASSURE  Vn  x  .  isnat(n)  ::  'in.lt  (x)  ::  RESULT (URITE  (nl  ,0,F  (tlBEXPR  (test  ,8) .  US  (body,  0)  .READ  (nl ,  0,  READ* 
U  CREAV(U,n2,  INT.O.CREAVIO.nl,  1  NT , 0, 1 RAflEO (FACTORIAL ,  INPUT (L  1ST  (n.x) )  .EOF)  ))))>) )  c  FRCTIn.x)  SPREF. 
i 310  Vn  .  .  isnat(n)  i:  .snatIO  ::  RESULT  (URITE  (nl.O.F  MBEXPR  (test  ,0) , MS  (body,  0)  .REAO  (nl, O.READ  (r.2, 0.CRE- 
AV 1 0,1.2,  INT,  0,CRERV(8,nl,  INT, 0, FRAME  0 (FACTORIAL,  INPUT  (LIST  (n,x> ) ,  EOF  ))!>>>>>  c  FACT(n.x)  (319) - ASSUME. 

I  |  |328  isnjt  (n)  s  TT  (320) - SASSUME. 

|  |  1 32*  1  isnat(x)  s  TT  (321) - SASSUIlt. 

I  ;  i  . - . 

.  |  |  |  TRY  #U1V2/J  RESUl  T  (URITE  (n  1,0, -(ns 0)-.F  (It&EXPR  (test  ,0) , MS  (boc  !)  ,I1S  (body.O.FRAHEl (SP,n, x) > ) , FRAME  1  <SP» 

,..,.))>  c  FACT  (n.x)  CASES  -In.O). 

I  I  I  I  - 

|  |  |  I  |  TRY  #im:*l#3  RESULT  (URITE  (n  1,8,  -(n=0)-*F  (RBFXPRUtst,  0)  "Slbody, 0) , MS (body ,0,FRAHE1 (SP,n,x) )>  .FRAME- 
KSP.n.x)))  e  FRCTIn.x)  :  SASSUME  -InsO)  ?  FF  SIMPL. 

,|||  |322  -(n=0)  3  FF  (322) - SASSUME. 

Sill  |323  RESUl  T  (URITE  (nl ,  0..(n=0).F  (MBEXPR (test  ,0)  ,MS  (boay.O) ,  MS  (body,  0,  FRAME  1  (SP,n,  x)  >  >  .FRAME  KSP.n.x))). 

c  FRCTIn.x)  (321  322)  —  SIMPL  BY  321  322  LM4. 

,|||  - 


,i|| . . 

I  |  |  |  |  TRY  #1#1#2#1#2  RESULT  (URITE  (nl,0,.(n*8).F  (MBEXPR  (tost  ,0)  ,MS  (body, 8)  ,MS  (body,  0, FRAME  1  (SP.n.x) ) )  .FRAME. 

KSP.n.x)))  c  FRCTIn.x)  i  SASSUME  -(n*0)  e  UU 

I  I  |  |  1324  .(n*0)  3  UU  (324) - SASSUME. 

||||  1 325  TT  3  UU  (320  324)  —  USE  ARITH1  328  324. 

|  |  |  |  1326  TT  s  UU  (320  324)  —  INCL  32S. 

Mil  . 

,|||  - 

|  |  |  |  I  TRY  #1#1#2#1#1  RESULT  (URITE  (nl,  O,-(n»0).F  (MBEXPR  ( test ,  0) , MS  (body, 8) , MS  (body, 0.FRAME1  (SP.n.x) ) )  .FRAME. 

l(SP.n.x)))  c  FRCTIn.x)  t  SASSUME  -(n*0)  3  TT  SIMPL. 

I  I  I  |  1 327  -(n.8>  3  TT  (327) - SASSUME. 

|  |  |328  I.\n  x  .  isnat(n)..(.snal(x>-RESULT(URlTE(nl,O,F(M8E)'PR(test,O),HS<body,O),READ(nl,0,REOO<n2,O,CREA- 

(M0.n2.  INT.O.CREAVIO.nl.  INT,  O.FRAMEO  (FACTORIAL,  INPUT  (L  IST(n.x) ) .  EOF)))))))),  UU)  .UUKpredln)  ,x*n>  c  (An  x  . .snat (- 
n  .'( i-n.1t  («>.FACT(n.x),UU),UUI  (pr«dln),x  :n)  (319)  —  BPPl  319  (W«d(nl  x»n. 

I  |  |323  PESULT (URITE (nl ,8,F  (MBEXPR ( test .0) , MS (body, 0)  .FRAME  1  (SP.prtd (n) , x:n) ) ) )  c  FACTIn.x)  (319  320  32- 

1  327)  —  SIMPL  328  BY  320  321  327  LM1  ARITH2  ARITH3  RRITH4. 

I  I  I  I  I  . 

|  I  I  |  |  |  TRV  11#1V2#1»1#1  RESULT  (IIRITKnl.O.F  (MBEXPRItest, 0).  MS  (body,  Ol.FRRMEKSP, prod  (n),cn))))  cFACT(n.x). 

I  I  I  I  I  — . 

|  |  |  |  1 330  RESULT  (UPITE  (nl  ,0,-(n=0)  -.F  (M8EXPR  (tost ,  0) .  MS  (body,  0)  .MS  (body,  0,  FRAME  KSP.n.x) ) )  .FRAME  1  (SP.n,  x) ) )  . 

c  FACT(n.x)  (319  320  321  327) - SIMPL  329  BY  321  327  LH2. 

I  I  I  I  . 

|  |  |  |331  RESULT  (URITE (nl.O, -(n=0)-F  (MBEXPR  ( test ,  0) ,  MS  (body,  0)  ,MS  (body,  0,  FRAME  1  (SP.n.x)))  .FRAME  l(SP,n,  x) ) )  c. 
FACTIn.x)  (319  320  321)  —  CASES  -(n.O)  330  326  323. 


,  |332  Vn  x  .  isnat(n)  n  isnat(x)  it  PfSULTMIRITEInl.O,  [At  b  .CONOIt  ,b*F  (t  ,b) ,  10)  KMBEXPR  <  tes  t ,  0)  .MS  (body , . 

0),  RE  AO  (nl .  0,  READ  (n2,f.CREAV(0,n2,  INT.O.CREAVIO.nl,  INT,  O.FRAMEO  (FACTORIAL ,  INPUT  (L  1ST  (n,  x) ) ,  EOF))))))))  c  FACTIn,. 
.1  (3191  —  SPREF  331  BY  227  280  261  320  321  LM3  LM1. 


!  1333  Vn  x  .  i  snat  (n)  i:  isnat(x)  ::  RESULT  (URITE  (nl.O.IIHILE  (M0EXAR  (tost,  0) ,  MS  (body,  0) ,  READ  (nl  ,0,  READ  (n2, 0.C* 
PE  AY  |0,  n2,  INT,  O.CREAV  (8,  nl,  INT,  O.FRAMEO  (FACTORIAL,  INPUT  (LIST(n.x)l  .EOF) ) ))))))  e  FACTIn,  x)  - INDUCT  318  332. 

I  . 

334  Vn  x  .  i snat  (n)  t:  isnat(x)  it  APPLYlFACTORIAL.n, x)  c  FACTIn, x)  —  SIMPL  333  BY  207  208  210  214  280  2. 
oi  Sb.  30b  307  318  311  316  TH13  THIS  TH10  TH12  THU  THS  THU  TH2  TH7  TH3  TH1. 


t 
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APPENDIX  8 

Proof  of  the  McCarthy  Airline  Reservation  System 


8.1  List  of  LCF  commands 


S3*  . APPLY,  .FUNCT,. PASCAL,. FUNCCOtlP,. IIP,. SP; 

TRY  SlflPLi 

TRY  INDUCT  .REPEAT; 

TRY  I  SPREFj 

TRY  CASES  '(*11 ( Isq) >3) ; 

TRY  3  SIMPL; 

TRY  2;  USE  ARITH1  . i  QED; 

TRY  J  SIMPL | 

LABEL  INDUCT; 

TRY  2  SPREF; 

TRY  CASES  -(•ll(nq)>3>! 

TRY  3  SIMPL; 

TRY  2;  USE  ARITHi  - ;  QED; 

SS+  .CONO,  .10; 

TRY  1  SIMPL; 

APPL  .  INDUCT,  t«l  ll  i s q ,  mtr pa  Ir  (stup'Jt  ( isq,p,q>  ,osq>  ,ltupdt  ( j sq , p , q )  ,wlupdt  ( i sq , p , q) ; 
SIMPL  -| 

TRY;  DEO; 
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8.2  Printout  of  the  proof 


(TRY  #1  Visq  osq  p  q  .  isufsq(isq) 
OMNG  (p.q,  isq.osq)  S I MPL  . 


tsulos(osq)  i:  isint(p)  i!  isint(q)  :  RPPLY(McCRRTHY,p,q,  isq.osq)  c  BO* 


,  |  TRY  tltl  Visq  osq  p  q  .  Isulsq(isq)  ::  isulostosq)  :!  ismt(p)  ::  isln(lq)  ::  OUTPUT  (-(I1EXPR  (rq  0,MS(B00Y,» 
0 ,  RERO  (s  t ,  O.RERO  (u  1 , 0 ,  FRRflE  1  (p,<(,  isq.osq) ) ) ) )  *3)  -REPEAT (AS  (600Y.0)  , MBEXPR  (mkbexpr  1  (not , ml  ro  I  (cq.rq ,ml  numcons  t  (3)  * 
) ) ,  0)  ,  0,H3  (R00Y.0,  RERO  1st  ,0  RERO (u I  ,0,  FRAME  1 (p.q, i sq.osq) >  > >  > ,MS  ( BOO  Y ,  0 ,  RERO  (s  t ,  0 ,  RERO  <  w  1 , 0, FRRME  l(p,q, isq.osq))* 
)))  c  B00HNG(p,q,  isi.osq)  1N0UCT  308  . 


|TRY  Visq  osq  p  q  .  iswtsq(isq)  i:  isulos(osq)  ::  isint(p)  ::  isint(q)  ::  0UTPUT(-(MEXPR(rq,0,MS(B* 

0,RER0(st,0,REflO<ul ,  0 ,  FRflnE  1  (p,<(,  isq.osq))  )> )  «3>-*UU(MS  (BODY,  0) ,  MBEXPR  (ml  bexprl  (not ,  ml  re  I  (eq.rq.mi  numcons  t  (3)  » 
)), 0), fl,MS( BOOY, 0, RERO  (st.O, RE R0(ul ,  0,  FRAME  1  (p,q,  i  sq,  osq) ) ) ) ) ,  M3  (BODY,  O.RERO  (st,0,RER0(ul ,  0,  FRRME  l(p,t(,  isq.osq))- 


00Y 


)))  c  BOO)  .'NGIp.q,  isq.osq) 

SPREF, 

1  1  1335 

isulsql isq)  3 

TT  (33S)  —  SRSSUME. 

1  1  1336 

iswlos(osq)  r 

TT  (336!  —  SRSSUME. 

1  1  1337 

ismt(p)  =  TT 

(337)  —  SP-3UME. 

1  1  1338 

1  s  1  n  t  ( q )  s  T  T 

(338)  —  SRSSUME. 

-(ell 

I 

I 

UME 

I 

I 

339) 

I 

I 

I 

UME 


UME 

I 


|  TRY  nmmm  OUTPUT  (-(*  1 1  ( I  sq)  =3)  -uu.ns  (BOOY ,  0,  FRRnE2  (p ,  q,  I  sq,  osq) ) )  c  BOOUNGIp.q,  isq.osq) 

i sq) *3) . 


COSES  * 


|  |  TRY  #l#l*(Xfl*3  0UTPUT(-(ell(isq>*3>*UU,MS(B00Y,0,FRflME2lp,q,  isq.osq)  > )  c  B00l.lNG(p,q,  isq.osq)  :  SRSS* 
- (e 1 1 ( i sq) *3)  =  FF  S1MPL. 

|  1 339  -loll ( i s T )  =  3 )  s  FF  (339)  —  SRSSUME. 

|  | 340  OUTPUT(-(*ll(isq)-3)*UU,MS(BOOY,0,FRfiME2(p,q, isq.osq)))  c  BOOUNGfp.q,  isq.osq)  (335  33b  337  338* 
---  S I MPL  BY  335  336  337  338  339  LM3. 


j  |  TRY  #1#K1#1#2  OUTPUT  (-(e  1 1  <  isq)«3>-*UU, MS  <800Y,®,FRRME2<p,q,  isq.osq) ) )  c  B00I  ING<p,q,  isq.osq)  i  SRSS* 
- (« ( 1 ( i sq) »3)  £  UU 

|  |541  -(ell(isq)«3)  i  UU  (341)  —  SRSSUME. 

|  1 342  TT  s  UU  (335  341)  —  USE  RR1TH1  341  335. 


|  |  TRY  VlllVlVlVl  OUTPUT  (— (el  1  ( isq)  «3)  -«UU ,  r>S  (BOOY ,  0 ,  FRRME  2  (p ,  q ,  isq.osq)))  c  Boot  INGtp.q,  isq.osq)  •.  SRSS* 
- ( e i 1  (  i  sq ) x 3)  S  TT  SIMPl. 

|  1 343  -(• 1 1 ( isq)*3)  3  TT  (343)  —  SRSSUME. 

|  |344  OUTPUT (-<• 1 1 < 1 »q)«3) -UU, MS (BOOY, 0.FRRME2 (p.q,  itc  , esq) > >  c  BOOL  INC  p,q,  Isq.osq)  (343) - SIMPL* 

BY  343  THG. 


I 


1 345  OUTPUT  (-(0 1 1  ( isq)  «3)-*UU,HS (BOOY,  0, FRRME 2  (r  q, isq.osq) > )  c  ROD)  ING (p.q,  1  sq, osq)  (335  336  337  338)  * 
CRSE3  -<r  1 1 ( isq>  =  3>  344  342  340. 


346  Visq  osq  p  q  .  isulsq(isq)  ::  isnlos(osq)  ! :  isint(p)  1:  ismt(q)  ::  OUTPUT  <- (I1EXPR  (rq ,  0 ,  MS  (BOO Y ,  0 ,  R* 
ERO  (s  t ,  0,  RFRO  (u  I  ,  0 ,  FRfllir  1  (p.q.  isq.osq)))))  *3)  *UU  (MS  (BOOY,  0) ,  MREXPR  (ml  h«*prl  (not  ,ml  re  I  (nq ,  r  q,  ml  ni.mcons  I  (3)))  ,0)  ,0* 
, MS  (BOO Y,  O.RERO (s  t . 0 , RERO (ul , 0, FRAME  1  (p.q.  isq.osq) ))))  ,MS (BOOY, 0 , RERO (st , O.RERO (u I , 0, FRAME  1  (p.q,  isq.osq) ) ) ) )  c  B* 
001  INGIp.q,  isq.osq)  - SPREF  345  BY  335  336  337  338  LI19  LM2 . 


I  j  |  TRY  ttiaviz  V 1  sq  osq  p  q  .  isul  q(isq)  ::  isulos(osq)  ::  isint(p)  :!  isinl(q)  i!  OUTPUT  (- (HtXPR  (r  q ,  0 ,  MS  <B* 
ODY,  0,  RFRO  (st,  O.RERO  (» 1, 0.FRRIIE1  (p.q,  isq,c;q)))))«3)-(*B  T  I  . BxCONO  (T.F  (B,  T,  I ) ,  10)1  (IIS  (BOOY,  0) ,  MREXPR  (ml  boxprl  (* 
no  t  ,ml  rn  I  (oq.rq.ml  numcons  t  (3) ) )  ,0) ,  0 ,  MS  (BOOY,  0,  RERO  <s  t .  0 ,  RERO  (ul ,  0,  FRRME  1  (p.q,  isq.osq) ) ) ) )  ,MS  (BOOY,  O.RERO  ( s  t ,  0 ,  R  * 
EPDIul.O.FRfiMEKp.q.  isq.osq)))))  c  B00I  ING  (p.q,  isq.osq)  :  RSSUME  Y  isq  osq  p  q  .  iswlsqli* 

sq)  11  1  sulos  (osq)  ::  ismt(p)  ::  isint(n)  :i  OUTPUT  (- (ME  XPH  (rq,0,  MS  (BOOY,  O.RERO  (s  I ,  O.RERO  (u  1 , 0,  FRfiMEl  (p* 

,  q,  isq,  osq) ) ) )  )  =  3)-F  (MS (BOOY,  0)  .MREXPR  (ml  be> pi  1  (not , mire  I  (eq, rq, ml  numcons ( (3) ) ) ,  0) ,  0, MS  (BOOY,  0,  RERO  (s  t ,  0 ,  RERO  (u  I  » 
,  0,  FRAME  1  (p.q.  isq.osq) ) ) ) ) .  MS  (BOOY,  0,  RERO  (st ,  0,  RERO  (u  1 , 0,  FRAME  1  (p,  q,  Isq.osq) ))) )  c  BOO)  ING  (p.q,  isq.osq)  SPRE* 
F 

|  |  |  34  7  Visq  osq  p  q  .  iSHtsq(isq)  :i  isulos(osq)  ::  isint(p)  ::  isint(q)  it  OUTPUT  (-(MEXPR  (rq ,  0,  MS  (BOOY ,  0 ,  R- 
ERO  (s  I  ,  0.  RERO  (w  1 , 0,  FRAME  1  <p,q,  isq.osq) ) ) ) )  =3)  -*F  (MS  (BOOY,  0)  .MBEXPRIml  bexpr  1  (not ,  ml  re  I  (eq,  rq ,  ml;  numcons  I  (3)  ))  ,0)  ,0,* 
MS(B00Y.0,REA0(st,0,RER0(ul , 0, FRRME 1 (p.q, 1 sq.osq) ) ) ) ) ,MS (BOOY , 0, RERO (s t , 0, RERO lu 1 , 0 , FRRME  (p.q,  isq.osq)))))  c  BO* 
0)  I NG  <p  q ,  1  sq  ,  osq)  (347) - RSSUIIE. 

)  )  1 348  isulsq(isq)  s  TT  (348)  —  5R5SUME . 

|  |  |349  isulos(osq)  £  TT  (349)  —  SRSSUME. 

|  |  1 350  isint(p)  s  TT  (350)  —  SRSSUME. 
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j  |  1 351  ismt(q)  !  TT  (351)  —  SlqSSUnP . 


j  |  |  |TRY  OUTPUT  (-(e  1 1  ( isq)=3)-*C0N0(NBEXPR(ml  be>prl  (not  ,ml  re  I  (eq.rq.ml  numconst(3) ) )  ,0>  ,F  (MSIBODY,  0) - 

( MBEXPR  (ml  boprl  (no  t,n  re  I  (eq.ro, ml  numconst (3) ) )  ,0)  ,0) ,  10, US (BOOY, 0, MS (BOOY, 0, FRRME2 (p , q,  Isq.osq) ) ) )  ,HS  (RODY,  0,  F» 
RRME2(p,q,  isq.osq) ) )  c  BOOK  INC  (p ,  q,  i  sq,  osq)  CASES  ->(•!  1  ( isq)=3) . 


|  |  |  |  |  TRY  #1#1#2#1#3  OUTPUT <-!e 1 1 ( isq) =3)-C0N0 (MBEXPR (mi  bo>pi  1 (not , ml  re >  (eq,rq  ml  numcons  1  (3) ) ) ,  0) , F  (US (BOD* 
Y,  0)  .MBEXPR  (mkbe>prl  (no  t  ,ml  re  >  (eq,i  q,mi  mimconst  (3)))  ,0)  ,0) ,  10 ,  MS  (BOOY,  0,  MS  (BOOY,  0.FRLME2  <p,q,  i  sq.osq) ) ) )  ,MS  (BODY. 
,0,FRRME2(p,q,  isq.osq)))  c  POOH  INC.  (p ,  q,  isq.osq)  :  SRSSUME  -(e 1 1 ( isq>*3>  s  FF  S1IIPI. 

|  |  |  |  |352  —  ( e  1 1  ( isq)  a'J)  s  FF  (352)  —  SRSSUME . 

|  |  |  |  1 3 53  OUTPUT  (-<*  1 1  ( isq)  Ol-CONO  (MBEXPR  (ml  bevprl  (not  ,ml  re  I  (eq.rq, ml  mimconst  (3) ) ) ,  0)  ,  F  ((IS  (BODY,  0) ,  MREXPR- 

(mkbe»prl  (not  ,  ml  re  I  (eq , rq , mL  numcons  t  (3)) )  0)  ,0) ,  10,  MS  (BOOY,  0 ,  ^1S  (BOOY ,  0 ,  FRRF1E2  (p,q,  isq, osq) ) ) )  ,HS(B00Y,  0 ,  FRAME  2  (p- 

,q,  isq.osq)))  c  B00I  INC  (p.q,  Isq.osq)  (348  349  350  351  352)  —  S1NPL  BY  348  349  350  351  352  LM3. 


|  |  (TRY  #1#U2#U2  OUTPUT  (-(el  1  ( nq)r3)->C0Hu!ilt)EXPR  (ml  be»prl  (not  ,ml  re  I  (eq,rq,mt  numcons  t  (3) ) ) ,  0)  ,  F  (MS  (B0D» 
Y,  0)  .MBEXPR  (ml  be-pr  1  (not ,  ml  r  e  I  <*q,rq,mi  numconst  (3) ) ) ,  0) ,  0) ,  10,  IIS  (BOOY,  0,  MS  (BOOY,  0,  FRRME2  (p,q,  isq.osq) ) ) ) ,  MS  (BODY — 
,0,FRflME2(p,q,  isq.osq)))  c  BOOT  INGIp.q. isq.osq)  :  SRSSUME  - 1  e 1 1 ( i sq ) » 3 )  s  UU 
|  |  |  |  1 354  -(elli isq) <3>  i  UU  (354)  —  SRSSUME. 

|  |  |  |  j 355  TT  =  UU  (348  354)  —  USE  RR1TH1  354  348. 


I  I  I  I  1  TRY  mmiitlil  OUTPUT  (-(e  1 1  <  i  sq)  *3)  -COMO  (MBEXPR  (ml  be*pr  1  (no  t ,  ml  re  I  (eq.rq,  ml  numcons  t(3))),0),F(US(BD0- 
Y ,  0) ,  MBEXPR  (ml  he»pr  1  (no  t  ,m4  re  I  (eq,rq,mi  mimconst  (3) ) ) ,  0)  ,0) ,  10,  MS  (BOOY,  0,  MS  (BODY,  0, 1  RRME2  (p , q ,  i  sq ,  osq) ) ) )  ,  NS  (BODY- 
, 0, FRAMES  (p,  q,  isq.osq) ))  c  BOOB lNG(p,q, isq.osq)  :  SRSSUME  -(e ) 1 ( i sq) *3)  *  TT  31MPL. 

|  |  |  |  | 356  -(ell (isq) *3)  s  TT  (356)  —SRSSUME. 

I  |  1 3 5 7  t \ isq  osq  p  q  .  isu(sq(  isq) «( isu(os (osq) -•(  is  int  (o>  *(  is int  (q> -OUTPUT  (- (MEXPR  (rq,  0, MS  (BOOY,  0,  READ  (s» 
t ,  0,  PERO  (w  1 , 0,  FRAME  1  (p.q,  i  sq,  osq) ) ) ) )  *3)  -F  (MS  (BOOY,  0)  .MBEXPR  (m  Never 1  (not ,  ml  re  I  (eq,rq ,  ml.  numcons  t(3))),0),0,MS(B0» 
DY,  0,  READ  (st  ,0,REA0  <wl  ,0,  FRAME  l<p,q,  isq.osq) ) ) ) ) ,  MS  (BOOY,  O.REFO  (s  t ,  0,  RERO  <u  1 , 0.FRRI1E1  (p ,  q.  I  sq ,  05<)>  > )  > ) ,  UU) ,  UU)  ,  U- 
U)  ,UU)  ( ta  I  1 1  ( isq)  ,ml  pa  ir  (stupHt  <  itq,p,<|)  .osq)  .stupMt  ( isq, p.q) ,  u  lupclt  ( isq,p,q) )  c  tXisq  osq  p  q  .  i su Isq  ( i sq )  -  ( i  sw- 
(os  (osq)  -  ( is  mt  (p)  -  ( is  mt  (q)  -BOOT  lNG(p,q,  isq.osq)  ,UU)  ,UU)  ,UU> ,  UU)  ( t  A 1 1 1  (Isq)  ,mi  pair  (stupdtl  i  sq ,  p ,  q)  ,  osq)  ,  s  tupdt  ( - 

isq,p,q>  ,u  lupdt  ( isq.p.q) )  (347) - RPPL  347  taili(isq)  mlpa  ir  (s  tupdt  ( isq.p.q)  ,osq>  S  tupdt  ( isq ,  p’,  q)  u  I  upd  t  ( I  sq  ,  - 

P.q)  ■ 

|  |  |  |  1 358  OUTPUT  <-<e  1 3  ( isq)  =3)  -F  (MS (BOOY,  0) , MBEXPR  (ml  bevprl  (not  ,mYre  I  (eq.rq.mi numconst  (3) ) )  ,  0)  ,  0,  MS  (BODY,  0- 
.FRAME3  (p.q,  isq.osq) )) ,  MS  (BOOY,  0,  FRAME3  (p  ,q,  isq.osq) ) )  C  BOOlINCtp,  Isq.osq)  (347  348  349  350  351  356)  --t  S1H- 
PL  357  BY  348  349  350  351  356  IM7  LM2  LM5  AR1TH2  RR1TH3  RR1TH4  RRITH5  LM4 . 


|  I  |  |  |  |  TRY  *1*UI2#H'1J'1  OUTPUT  (-(e 1 3 ( i sq) *3>-F  (MS  (BOOY,  0) ,  MBEXPR  (ml  bexpr  1  (no  t ,  ml  re  I  (eq,  rq ,  ml  numconst  (3) >  >  - 
,0)  ,  0,  MS  (BODY,  0,FRRME3(p,q,  isq.osq) ) ) ,  NS  (f.00Y,fl,FRRME3  (p,q,  isq.osq)) )  c  BOOL  INC  (p ,  q,  isq.osq) 

I  I  I  I  I  . 

|  |  |  1 359  OUTPUT  (-(e  1 1  ( isq)«3)-C0H0(NBE/PR(mi  bo>prl  (not , mi  rr|  (cq,rq, ml  mimconst  (3) )),  0)  ,F  IMS  (BOO  i ,  0) ,  MBEXPR- 
(ml  be»pr  1  (no t , ml  re  I  (eq , rq,mL numcons  t  (3)  > ) ,  0)  .0) ,  10, MS  (BOOY, 0,113 (BOOY , 0.FRRME2 tp,q,  isq,osq) )  >  >  ,IIS  (BODY,  0 , 1  RRME2  (p» 
,q,  isq.osq)))  c  BOOt  INO (p, q,  isq.osq)  (347  348  349  350  351  356)  —  SIMPL  358  BY  227  281  348  349  350  351  356  LM. 
8  LM6. 


|  j  |  |  3  (jo  OUTPUT  (-(e  1 1  <  isq)  »3> -COMO (MBEXPR  M  ‘bevprl  (not  ,mi  re  I  (eq.rq,  ml  numconst  (3>>),0>,F(1'(R00Y,0>,IIREXPR(m- 
I  hevpr  1  (no  t ,  ml  re  I  (eq,  t  q,  ml  numconst  (3) ) ) ,  0) ,  0) ,  10,M5  (P.OOY,  0,MS  (BOOY.P  FRAME- (p,q, isq.osq) )) )  ’10  (BODY ,  0,  FRRME2  (p ,  q- 
,  isq.osq)))  c  BOO)  1NG (p, q , i sq, osq)  (347  348  349  350  351)  — -  CRSES  ■  <e  1 1 ( i sq) *3 )  355  355  3oo. 


|  |  1 361  Visq  osq  p  q  .  isutsq(isq)  ::  isw(os(os<|>  ::  isml(p)  ::  isint(q)  : :  OUTPUT  (  —  <l1EXPR(r<»,  0.  IIS  (POOY,  0,  R  — 
ERO  (st  ,0,  READ  (ul ,  0,  FRAME  1  <p,q,  isq.osq) ) )  >  >o)-UB  T  (  .  8rC0N0  (T,F(B,T,t),IO)l(MS  (BOOY,  0)  .MBEXPR  (mi  be .  pr  1  (no  t ,  ml  r- 
e  I  (eq.rq,  ml  numconst  (3)  I ) ,  0) ,  O.MS  (BOOY,  0,  RCRO  (s  t ,  0,  RERO  (u  I ,  O.FPRIIE1  (p.  q,  isq.osq) ))))  ,MS  (BODY,  0,  REMO  (:,  t  ,0,RER0(u  l,» 
0.FRRME1  (p,q,  isq.osq) ))) )  c  BOOL  INGtp.q,  isq, osq)  (347) - SPREF  360  BY  280  348  349  350  351  LM9  LM2, 


|  1 36-  Visq  osq  p  q  .  isu)sq(isq)  ::  isutos(osq)  ::  isint(p)  ismt(q)  OUTPUT  (-(IIEXPR  (rq,  0 ,  MS  (BODY,  0 ,  REfi » 
Q  ( s  t ,  0  REfi0<nl,0,FRfiMEl(p,q,  isq.osq)')!)  3)  -REPEAT  (MS  (B00Y.0) ,  MBEXPR  (ml  bevprl  (not ,  ml  i  e  I  (rq,rq  ,m(  numconst  ( 3  > )  ) ,  0 )  — 
,  0,  MS (BOOY,  0,  RERO  (st ,0, RERO (u  1 , 0,  FRAME l(p,  i, isq.osq)) ) )) ,  MS (BOOY,  0,  RERO (s t ,  0, RERO (u 1 ,0, FRAME  1 (p,q,  isq.osq) ) ) )  )  c- 
B00I  IMG (p , q , i sq , osq)  - INDUCT  346  3G1. 


1 363  Visq  osq  p  q  .  isutsq(isq)  ::  iSHlos(osq)  ::  tsmt(p)  ::  isint(q)  ::  APPLY (McCRRTHY, p , q ,  i sq , osq)  c  BOOLI¬ 
NG  (p,  q ,  I  sq , osq)  —  SIMPL  362  BY  207  208  210  280  303  326  333  334  LM1  TH2  TH5. 
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